Re: Patches and win32 build?

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 "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]