On Sun, 16 Feb 2003, Charles Wilson wrote:
> 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/Makefile.in. 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?
>
> --Chuck
Chuck,
I'm not libtool-savvy, so this may seem like a stupid question -- if it
is, let me know. However, I've been kinda following this discussion, and
haven't seen it answered. So here goes:
- How hard is it to add the capability to pass linker arguments through
the LD variable? What's involved? It seems (to me, anyway) like this
would be the least painful solution all around...
This is probably totally irrelevant and out of line. I'll just shut up
now.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
-- /usr/games/fortune
--
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/