Re: [avail for test] libtool-devel-20030121-1

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Max Bowsher wrote:
> 1.4e isn't a specific version. It just means "some cvs checkout after the
> 1.4d release"
Right.  But when?  And on which branch?  1.4-branch CVS, or HEAD CVS 
(which is to say, pre-1.5)?  Granted, libtool's CVS organization and 
branch naming could be better, but AFAIK KDE still uses a 1.4.x-style 
"1.4e" from the 1.4 branch, and not a 1.5-style "1.4e" from the HEAD branch.

> This seems like a good time to mention that I ran into this problem building
> gtk+ (or glib), I forget. It wanted -luuid, but -luuid is a static archive,
> which libtool doesn't currently like. I had to hack libtool as Ralf mentions
> above to get it to work.
ARGH.  That defeats the whole purpose of the *POLICY* change in libtool. 
 I do NOT want to be in the business of supporting a forked version of 
libtool that disagrees with mainline on a *fundamental* policy issue.

** you can't build shared libraries that depend on static libraries, 
when using a "modern" libtool (e.g. HEAD CVS, pre-1.5) **

the only exception to this rule are the compiler runtimes, such as 
libgcc, libg++, libsupc++, libstdc++, libg2c, etc.

If you have a problem with the policy, the place to fix it is NOT to 
hack up libtool.  Instead, get shared versions of your dependencies. 
Here are all of the w32api libs that currently build as static archives, 
and are not simply import libs for Win32 dlls, and do not build shared:

libdxguid.a
liblargeint.a
libscrnsave.a
libscrnsavw.a
libuuid.a
libdinput.a

e.g. the EXTRA_LIBS in winsup/w32api/Makefile.in

EXTRA_LIBS=libuuid.a libscrnsave.a libscrnsavw.a libdxguid.a liblargeint.a

Now, scratch your itch: you have a problem with libuuid.a; figure out 
how to build it as an dynamic library (hint:

gcc -shared -Wl,--export-all -Wl,--out-implib=libuuid.dll.a -o 
cyguuid-0.dll uuid.o

works) but you'll have to link your client using 
--enable-runtime-pseudo-reloc.  Eventually this will become the default 
for ld on cygwin I hope, but isn't yet -- and currently it is hard to 
pass compiler and linker flags like this thru libtool.

I'm not sure what the best workaround is right now; perhaps it is time 
to push for --enable-runtime-pseudo-reloc as the default on cygwin ( but 
 not mingw )?

--Chuck

P.S. the problem must have been in gtk, because I didn't have that 
problem compiling glib-2.2.0.

P.P.S. cursory inspection shows that

  largeint.c is the complete contents of liblargeint.a, and includes 
"bad" data types -- if you build this as a DLL, you'll need to use 
--pseudo-relocs to link against it.

  dxguid.c is the complete contents of libxguid.a.  --pseudo-relocs needed.

  ditto dinput.c, libdinput.a

  scrnsave.c is the complete contents of BOTH libscrnsave.a AND 
libscrnsavw.a.  However, I believe that all public symbols in scrnsave.c 
are "good" data types; this should be easily dll-izable.

 shell32.c contains "bad" data types, but it is not the entire contents 
of libshell32.a.  libshell32.a is created as an import lib for the 
MS-provide shell32.dll, but then shell32.o (created from shell32.c) is 
appended.  So, libshell32.a is a "hybrid" like libcygwin.a -- but it 
will be detected as an import lib.  So there's no need to "dllize" this. 
  ('course, philosophically, I dunno if this structure is a good idea. 
 Every program linked against -lshell32 will get its own private copy 
of the data provided by shell32.c -- what if it changes? But making 
those objects shared is bad -- because they are "bad" data types, 
leading to the --psuedo-reloc problem)

  kernel32.c provides functions only, and is appended to libkernel32.a. 
 No probs here.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/