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 _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia