Re: [gimpwin-dev] g-libs renaming and DIR emulation

[Tor Lillqvist <tml iki fi>]

Charles Wilson writes:
 > This is terrible.  Both the hard-coded 'lib' prefix and the .micro 
 > versioning.  I'll address each separately:

 >   If ALL platforms have DLL's with the same name, then you get runtime 
 > loading errors due to conflicting runtime libs.

No, only mingw and MSVC (which I wouldn't even call separate
platforms, as they use the one and same C runtime) produce the same
name DLLs. Cygwin DLLs would be created with a "cyg" prefix by
libtool. As for PW an UWin, I have no idea. Does libtool support
these?

 > > Another somewhat related issue is the addition of the micro version
 > > in the dll name.

Note that this part of Hans's mail was based on a
misunderstanding. The micro version number isn't included in the DLL
name, it just looks like that as long as the micro version keeps
increasing while binary_age is kept at zero...

 > DLL's on windows should be named using earliest supported interface 
 > version.  Thus, using libtool's --version 5:4:3, you would get 
 > cyg<name>-2.dll.

(Or for a DLL using the MSVCRT runtime, lib<name>-2.dll.) Well, that
is exactly what now happens in current CVS glib, but what Hans didn't
like.

 > Do gtk / glib follow the "real" libtool conventions on library 
 > versioning? (e.g. InterfaceVersion:Revision:BackwardCompatibility) Or do 
 > those projects try to tie the package-release-version to the 
 > shared-library-version?  (I'm dreadfully afraid that the answer is yes...)

No need to be afraid. Yes, they use the "real" conventions in the
correct way, to the best of my knowledge. (Correct me if I am wrong.)

--tml