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

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Igor Pechtchanski wrote:

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

You could -- but that runs counter to the "libtool way'.  Libtool 
doesn't even let the compiler determine which system libraries get 
linked -- at least, not directly.  Instead, libtool parses the output of 
'gcc <args> -v' and 'gcc -nostdlibs <args> -v', and stores the 'crt.o' 
and 'libgcc.a' miscellany.

Then, when it's time to link a library, libtool uses ld directly, and 
adds the 'crt.0' and friends itself.

The idea is that libtool gets maximal information; nothing is hidden 
from libtool (e.g. gcc's spec file adding extra system libs, etc).  Now, 
some have argued [ahem, ahem] that libtool is trying to do too much. 
Maybe so.  But this is really such a minor issue (and my time is so 
limited) that I don't want to tackle that beast -- the effort is too 
high for the possible benefit.

Anyway, passing args thru LD -- kinda defeats the "libtool controls 
everything" idea.  In fact, I was surprised that the patch that let 
CC='gcc -mno-cygwin' work in libtool was accepted.  I was FLOORED when 
the "let CC contain any flag whatsoever" patch made it in.

Now, this may be an argument that "okay, the rules have been loosened; 
submit the patch and hope...". However, I'd rather play it conservative 
this close to a release.  I want the most common 4 cases, 
cygwinBuild/cygiwnTarget to work.  mingwBuild/mingwTarget.  And 
linuxbuild/cygiwnTarget, linuxBuild/mingwTarget.

those all work now.  Let's not break anything before 1.5 comes out; too 
many projects are holding off until libtool-1.5 is available before 
accepting cygiwn patches (esp. cygwin patches that *require* libtool-devel).

so that's the argument against a broad "LD can contain any random flag" 
patch.  what about a focused patch, that specifically allows 
--enable-psuedo-relocs?

Ugh.  How hackish.  I'd rather push for that to become the default 
behavior in binutils, than kludge up the (already nasty) libtool code 
with YASPE (yet another special purpose exception).

--Chuck


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