This is the mail archive of the cygwin@cygwin.com 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


Charles Wilson wrote:
> Max Bowsher wrote:
>>>> But, that's neither here nor there.  IF these crossbreed implibs
>>                                                 ^^^^^^^^^^^^^^^^^^
>> 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.

Besides, this means altering the platform to suit libtool. Talk about the
tail wagging the dog!

> The only alternatives for this particular problem seem to be:
>
> 1) punt.

Well, it's not like we've got many complaints about this.

> 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.

And, as I say above, is ridiculous. Libtool is supposed to assist
portability - no force platforms to redesign themselves.

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

Messy.

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

I like it. But it's not going to happen. So:
How about a flag, like -no-undefined ?
For example: -i-know-what-i-want-to-link-dont-interfere-please :-)

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

Punting is acceptable, if necessary. What do you think about my flag idea?

Max.


--
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/


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