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

[Charles Wilson <cwilson ece gatech edu>]

Tor Lillqvist wrote:
> 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?

AFAIK, not yet.  I mention them only to show that the problem space is 
larger than [MSVC=mingw | cygwin].   But eventually...

First step is to make sure that the mingw and cygwin versions of libtool 
work properly.  However, that seems to require an intermingled set of 
updates -- use the latest versions of auto*, cygwin-1.3.3 or later, etc. 
We're a-working on it...

(aside: one problem is that we currently have a logjam on cygwin.  No 
new packages are allowed in the cygwin net dist until after the new, 
revised setup.exe installer is released.  But that's been the hangup for 
about six weeks now.  This means no *official* libtool package.  Urg.)

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

Ah, I see.  So the release-micro-version-number is tied in to the 
libtool-ish "revision-of-current-interface" number?

>  > 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.) 

Correct.  Good, so far we agree. :-)

> Well, that
> is exactly what now happens in current CVS glib, 

Great!

> but what Hans didn't
> like.

Hans!!!  :-(

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

Great!

> (Correct me if I am wrong.)

I'll download current CVS and check.  Where do I do to get the 
win32-branch?  What repository, and branch tag do I use?  Or should I be 
looking at HEAD?

--Chuck