This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:


e.g. the EXTRA_LIBS in winsup/w32api/

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


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:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]