X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49817C56.5040106@cwilson.fastmail.fm>
Date: Thu, 29 Jan 2009 04:52:22 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: RFD: cygwin + *native* MinGW compiler
References: <BEBA87DEFCC94625AFD40845D6E627FE AT THOMAS> <49817A58 DOT 2080507 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <49817A58.2080507@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

Charles Wilson wrote:
[describe "old" libtool behavior; what I called "current gcc libtool"]
>  1) creates both a wrapper script foo and wrapper exe foo.exe in the
> build directory, and also (?) a copy of the wrapper script in .libs/
>  2) the wrapper exe execs the wrapper script via $SHELL
>  3) the wrapper script handles all the $PATH manipulations, and
> locates/execs the "real" exe

[contrast new libtool-git-ToT behavior]
> And that's the problem. I have a hunch that *right now*, if we dropped
> in git-master-ToT libtool into gcc, your configure incantation would
> fall over dead, because every executable's wrapper script (if built
> using libtool) would have the "wrong" format of path/to/real/exe inside
> _spawn("...") -- unless we dodged the bullet, as described above.

Wierd. It's been a while since I updated my local svn tree of gcc. It
finally finished, and I see that, in fact, current gcc trunk includes a
much newer version of libtool than I thought (2008-09-26==2.2.6ish, not
2007-03-18). So, in reality, *current* gcc libtool has the "new" behavior.

If that's working for you, Danny, then I guess gcc really did "dodge the
bullet" -- maybe libtool is never used in linking applications or test
progs within the gcc tree, so it's a moot point /for gcc/?

But, all the worries I listed still apply for *other* packages that
someone might want to compile using --build=mingw --host=mingw, when
$build is actually cygwin.  But it'd be wonderful to avoid all that
worry for the src/ tree!

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/