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:

But, that's neither here nor there.  IF these crossbreed implibs are
libuuid.a at least is static *only* - not crossbreed. So there really is no
way for libtool know to allow it except by name.
Ugh. You're right -- I was confused by the implicit rules in winsup/w32api/lib/ libkernel32.a and libshell32.a are crossbreeds, but the others (libscrnsave.a, libscrnsavw.a, liblargeint.a, and libuuid.a) are pure static. [The rest are pure import].

I really really REALLY don't want to special case this. I was able to avoid special-casing the compiler runtimes, by using libtool's existing ability to parse the output of gcc -nostdlib, and compare it to the "normal" link command to determine what libraries are, in fact, compiler runtimes.

Newer libtools (e.g. newer than the 20030121 release) allow compiler args to be passed in the CC variable, but not linker args thru the LD variable. This means there can be no easy solution ("turn libuuid.a into a DLL and import lib; set LD='ld --enable-runtime-pseudo-reloc'; and then run libtool"). Sigh.

The only alternatives for this particular problem seem to be:

1) punt. If you want -luuid, grab the single source file winsup/w32api/lib/uuid.c, and add it to your project's source. Or, messier, in your own makefile locate the system's libuuid.a, ar -x it, and include the resulting .o directly into your dependencies. You could be clever by (basically) recreating libuuid.a as a convenience (static) library within your project; then libtool wouldn't complain and you could still say -luuid (only, it would have -L<srcdir> in front of it).

2) delay. --enable-runtime-pseudo-relocs will be the default **on cygwin** someday (never on mingw). Wait until then, or push it now. In any case, once it is the default, then we can simply dllize libuuid, and then -luuid will grab the import library, and libtool will be happy. But this can never be the solution for mingw.

3) kludge. Put a special-case exception for -luuid and libuuid.a -- and the other four !@#$!@# static libs in w32api -- into the libtool code.

4) revoke the libtool policy; DLLs with static dependencies are just dandy.

All four alternatives suck. #4 is the worst; it won't happen. #2 won't help mingw. That leaves #1 and #3 -- and I hate kludges. How important is this? Is "punting" really such a bad idea?


Unsubscribe info:
Bug reporting:

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