Re: Patches and win32 build?

[Hans Breuer <Hans Breuer org>]

At 04:26 25.09.03 +0200, Cyrille Chepelov wrote:
> Le Thu, Sep 25, 2003, à 01:56:34AM +0200, Hans Breuer a écrit:
> > At 22:11 24.09.03 +0200, Cyrille Chepelov wrote:
> > > Le Wed, Sep 24, 2003, �  07:13:52PM +0000, debacle a �©crit:
> > > > On Wed, Sep 24, 2003 at 03:14:03PM +0300, Steffen Macke wrote:
> > > > > Sorry, this is my fault, component_feature.c is included
> > > > > in the DLL - but I missed to copy the new shapes.
> > > >
> > > > OK, thanks for the information.  If I send new patches to
> > > > dia - and I plan to do so - (how) can I help making the
> > > > patch win32-able?
> > >
> > > 1. Stick to the published glib/gtk APIs
> > > 2. Never assume that the path separator is /, use the glib macros
> > > 3. when in doubt, assume the linker is dumber than your worst dreams.
> > Which will also help on other 'dump' - i.e. non ELF - platforms. 
> > [In fact I like the win32 linker, which somewhat enforces a clean 
> >  dependency stack, no cross dependencies if you don't explicit 
> >  want them.]
>
> 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.
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)

> 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 ?

> [...]
> 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.

> > 16. Declare all your functions befre using them. Note : this is not
> >     a deficiency of the msvc compiler but some enforced coding style
> >     through pragmas (-FImsvc_recommended_pragmas.h)
>
> In fact, it's strongly recommended by c89 as well.
>
> Happy to see that I wasn't too off-mark :-)
How could you think you are ;-)

        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert