This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030121-1
Max Bowsher wrote:
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.
1.4e isn't a specific version. It just means "some cvs checkout after the
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.
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.
** 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:
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
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 )?
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