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

[Charles Wilson <cwilson ece gatech edu>]

Hans Breuer wrote:
> Hi Tor,
> sorry for complaining, but I would have preferred if two of your
> recent changes would have been discussed on the mailing list 
> first - or even could be avoided :)
>
> Renaming from glib-$(major.minor).dll
> -------------------------------------
>   to libglib-$(major.minor.micro).dll
>
> How far should it go ? Do you plan to rename all the gtk+ libs ?
> Even Gimp's libs ? What about external libs ?
>
> Some of my reasoning:
> Adding the lib prefix to glib gives three libraries in one name,
> though it is a matter of taste it's at least not mine ...
>
> But here are some 'hard' facts. Using the lib prefix may improve
> consistency with libtool and *nix, but it does decrease it with 
> the win32 platform conventions, even with earlier gtk+ versions.

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

Hard-coded 'lib' prefix.  (if this ONLY affects building with MSVC, then 
ignore this whole section.  I'm only worried if the hardcoded prefix 
affects all win32-ish platforms) There are several "mini-platforms" that 
exist on windows and all use the windows-native shared library loader 
and DLL format.  There's native (MSVC), mingw (perhaps interchangeable 
with MSVC, but the build procedure is different), cygwin, pw, uwin, etc. 
 If ALL platforms have DLL's with the same name, then you get runtime 
loading errors due to conflicting runtime libs.

Real life example: The netpbm package distributed with miktex contains 
"native" (MSVC?) style DLL's for libjpeg, libpng, libtiff, etc.  That 
is, these DLL's depend on msvcrt.dll for runtime services.  Back in the 
day, cygwin ALSO distributed DLL's for libjpeg & friends with 
*identical* names -- but these depended on cygwin1.dll for runtime 
services.  Unless you were *very* careful, you could run a cygwin 
application and pick up the netpbm-DLL's (== boom) or you could run the 
netpbm applications and pick up the cygwin-DLL's (also == boom).  I 
experienced the "boom" -- and decided to do something about it.

About a year ago, we hashed out a convention (between the cygwin, pw, 
mingw, ... platforms on i386) that DLL's should have distinct prefixes 
on the different win32-ish platforms, to promote peaceful coexistence on 
the same machine.  Thus, most (if not all) cygwin dll's now begin with 
"cyg" NOT "lib".

To do this, we added much functionality to the GNU linker and gcc, to 
enable the transparent use of 'cyg' prefixes (as well as whatever 
prefixes the other platforms would like -- just add 
'--dll-search-prefix=foo' to the spec command for linking).  Also, since 
import libs specify the dll name, you can have 'libfoo.dll.a' be an 
import lib that points to 'cygfoo.dll' -- as on the cygwin platform. 
(And yes, we added functionality to the GNU linker so that it hunts for 
"libXXXX.dll.a" before "libXXXX.a", so that part's taken care of, too).

Note that work on libtool is progressing to make this sort of thing 
handled transparently on the unix-ish windows build platforms.

> IMO using the cyg prefix is a different issue and does not necessarily
> require 'lib' for the other cases. Forcing it for msvc build may give
> the impression that libtool is concerned, though it probably won't
> in the near or mid future. 

I'm not sure about the preceeding paragraph.  It might mean that my 
entire preceeding discussion was unnecessary, but then again, maybe not. 
 I'm not sure, since I didn't see the original message of Tor's to 
which Hans was replying.

> Another somewhat related issue is the addition of the micro version
> in the dll name. IMHO the Windows loader is quite able to handled
> micro api additions as may be shown by increasing the micro version
> (missing symbols in older versions). If we include the micro version
> in the dll name (as done on *nix) there is no such simple solution
> like creating a symbolic link, but some users will complyin and others
> will simply rename the dlls. Probably both things are not our intent,
> are they ?

The problem is you just can't use unix-like ld-config tricks on windows. 
 This is the solution advocated by the libtool people:

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.  (Since 5:4:3 is revision 4 of the implementation of 
interface 5, which is backwards compatible with the 3 previous interface 
definitions -- it is safe for applications linked against interfaces 5, 
4, 3 and 2 to load the 5:4:3 dll at runtime).  So, libtool uses (from 
5:4:3) "5 - 3 = 2" as the version number.  c:r:a => c - a.  On cygwin, 
dll's use 'cyg', not 'lib', as their prefix.  Import libs are named 
"lib<name>.dll.a" (yes, ld "knows" how to search for these, and does so 
in preference to .a -- but that shouldn't matter when using libtool. 
Static libs are named "lib<name>.a".  I don't know how mingw "should" 
name stuff, but this is how things "should" be named on cygwin.

(I've posted this link before on this list, but here it is again):
A discussion of DLL naming, and current (hacked) libtool behavior 
(scroll to bottom of the following message):
http://www.cygwin.com/ml/cygwin-xfree/2001-q3/msg00432.html
> If the real reason for adding the lib prefix was to get different
> library names for early - almost 1.2.x versions - and the new
> almost 2.0 versions, shouldn't we try to convince the gtk+ people
> to bump the version to 1.9 ?

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

See:
http://www.delorie.com/gnu/docs/libtool/libtool_.html
(naturally, all discussion in the libtool docs where it talks about the 
runtime linker "choosing" a particular revision of the DLL are 
meaningless on windows.  The MS runtime linker can't make "choices".  It 
loads the first DLL with the *exact* name it's looking for.)

--Chuck

P.S. current status of development autotools on cygwin:

automake-1.5 is included in the official cygwin net dist.
autoconf-2.52 is included in the official cygwin net dist.
official cygwin net dist of binutils supports the 'auto-import' 
functionality.
Robert Collin's hacked version of libtool interoperates with these 
tools.  Available here: 
http://www.neuro.gatech.edu/users/cwilson/cygutils/robert-collins/

Soon:
cygwin's binutils will turn on "--enable-auto-import" by default

Problems:
many projects are refusing to update their autoconf files to support the 
new autoconf-2.52 system, and are incompatible with it -- forcing 
developers of those projects to stick with 2.13.  Therefore, we (the 
cygwin people) are attempting to copy Debian's system, where both 
autoconf-2.13 and autoconf-2.52 are installed -- and scripts are used to 
automagically choose the "right" version for a given project.  This is a 
work-in-progress.

Dunno if there are similar difficulties between automake-1.4p2 and 
automake-1.5, but we'll handle them the same way.