RE: Odd behaviour when building on Win32 using MinGW

[Tor Lillqvist <tml iki fi>]

 > > Or would you require that all GLib-using software is configured
 > > with the same --prefix (on Windows, installed in the same
 > > location)?

Espen Harlinn writes:
 > Basicly - yes, or rather all glib using software should have it's own
 > private version of glib/atk/pango and so on. 

That sounds like a bad idea to me... so if somebody wants to upgrade
to a newer build of Pango, for instance, without changing anything
else, he wouldn't be able to do that?

 > Your compilation of GTK might not be 100% compatible with my
 > compilation, so for distribution purposes we must either have a
 > standard distribution for GTK, or a way to brand the dlls so they
 > wont get mixed up.

You do have a point. But I think your solution is way over the
top... 

 > And I'm using the following scheme to name the dlls

 > lib$(name)-$(branding)-$(compilersignature)-$(libraryversion)[-$(debugfl
 > ag)].dll

 > So building zlib 1.1.4 with C++ builder 6 results in a dll:
 >  libz-ewin-bcc6-1.1.4.dll (release version)
 > And
 >  libz-ewin-bcc6-1.1.4-d.dll (debug version)

 > Building zlib with MinGW results in
 >  libz-ewin-mingw-gcc3.3.1-1.1.4.dll (release version)
 > And
 >  libz-ewin-mingw-gcc3.3.1-1.1.4-d.dll (debug version)

So, basically you are saying, "there are several incompatible zlib
builds for Windows floating around, so I'll have to make yet another
one"? Why don't standardize on one of the existing zlib DLLs?

Why do you include the compiler version number, up to three levels, in
the DLL name? When you upgrade to gcc 3.3.2 (say, for instance some
serious bug is discovered in gcc 3.3.1 that affects your code), will
you produce new builds of everything?

Also, including the overall release version number of some library in
its DLL name(s) is something that generally isn't considered a good
idea. That's why libtool uses the interface age and related
concepts. The DLL name should stay the same as long as binary
compatibility is maintained.

Is your suggestion that everybody who distributes any software has to
build all the dependencies themselves, naming them uniquely? Sounds
hellish.

--tml