Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3E542F83.3000809@ece.gatech.edu>
Date: Wed, 19 Feb 2003 20:29:39 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: Max Bowsher <maxb AT ukf DOT net>
Subject: Re: [avail for test] libtool-devel-20030121-1
References: <3E502835 DOT 7060400 AT ece DOT gatech DOT edu> <Pine DOT GSO DOT 4 DOT 44 DOT 0302191024360 DOT 11788-100000 AT slinky DOT cs DOT nyu DOT edu>
In-Reply-To: <Pine.GSO.4.44.0302191024360.11788-100000@slinky.cs.nyu.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/