Re: Patches and win32 build?

[Cyrille Chepelov <cyrille chepelov org>]

Le Fri, Sep 26, 2003, Ã 08:13:58PM +0200, Hans Breuer a Ãcrit:

> > The win32 linker, enforcing a clean dependency stack ??? Uh. LINK.EXE
> The keyword was 'somewhat'. Of course unlimited dirty tricks are
> possible with the Micro$oft linker, but it usually it requires
> extra jumps through the loop.

I've been as far as building custom .lib files with a python script, so
define "dirty trick" (Not!)

> One of the problems with ELF I was refering to is having a global 
> function or variable in the executable having liba depend on libb,
> exe depend on both libs and libb depend on exe and the ELF
> user does not see a problem ...
>
> Another thing is if you don't explicit export a symbol it stays
> private to the module. At least the gnu linker seems to export
> anything which is possible without special handling. An even as
> gtk started to use something like -no-undefined it was broken
> (may have been an libtool issue though)

Mmmmh. Point taken. Though these days I'm wrapping almost everything I
can in anonymous namespaces anyway.

> > from Microsoft, perhaps, but I can assure you that the win32 *loader* is
> > happy to load certain spaghetti balls made of a mixture of Borland C++,
> > Intel C++ and Delphi (about a half-hundred DLLs total, absolutely messy,
> > you pull one DLL you get the 49 others free no matter what DLL you start
> > from. And of course if you dare recompile only a DLL, you risk shipping
> > a silently corrupt or silently vicious executable).
> How is this different in having a 49 dependency on *nix ?

None at all. My point was, that circular dependency spaghetti was quite
easily achievable on win32 if you use the "right" tools :-)

> > [...]
> > avoid c89 constructs until you (Hans) say that the primary Win32
> > compiler is happy with them.
> wouldn't happen any time soon, cause we have to stick with
> msvc 5.0 - 6.0 to get the right c-runtime (as used by the
> mingw build, msvcrt.dll) to be compatible.

Anyone feels like beaming that up to the wiki? Sounds like something we
need to show in a clear enough light

(might be a good thing to turn on any gcc warnings against c89 if we can
do that)

        -- Cyrille
        
--