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: <3E52D4F7.5060803@ece.gatech.edu>
Date: Tue, 18 Feb 2003 19:51:03 -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: Max Bowsher <maxb AT ukf DOT net>
CC: cygwin AT cygwin DOT com
Subject: Re: [avail for test] libtool-devel-20030216-1
References: <3E519478 DOT 6050108 AT ece DOT gatech DOT edu> <007f01c2d797$5fb5d1e0$78d96f83 AT pomello>
In-Reply-To: <007f01c2d797$5fb5d1e0$78d96f83@pomello>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Max Bowsher wrote:

> I've discovered something which is only a problem when doing a
> CC='gcc -mno-cygwin' compile - namely, that the new wrapper executables do
> execv("/bin/bash",...), which quite obviously, msvcrt doesn't understand.

cygwin-target(or mingw-target) libtool does not work at all unless you 
have a reasonably complete posix environment -- ditto autoconf, 
automake, etc.  In fact, this was the entire reason for the Earnie's 
MSYS fork of cygwin: he wanted the autotools to work, but he wanted the 
environment to give the "right" answers for a non-cygwin, ming-ish 
system, while a "real" cygwin platform does not do that.

Since the wrappers are only for running *uninstalled* executables, this 
shouldn't be a problem.  If it becomes a problem, the answer is simple: 
install the executable, and throw both wrappers away.

Besides, how did you run the SHELL wrapper, which has been a "feature" 
of libtool for years?  It has "#!/bin/$SHELL" right at the top -- and I 
don't think cmd.exe does pound-bang interpretation, and libtool never 
sets SHELL=cmd.  (or whatever the platform non-compliant shell is). 
NOTE: the source code for the exe wrapper, and the shell wrapper, both 
use the SHELL as detected during configure for the buildplatform; it is 
not hardcoded to /bin/sh.  E.g. on MacOS X it'll be /bin/zsh.

So my .exe wrapper explicitly uses "execve("/bin/$SHELL <scriptname> 
<args>") while <scriptname> has -- and always HAS had -- "#!/bin/$SHELL" 
at the top of it?  I fail to see the problem.

Further, why are you trying to run the uninstalled executable from your 
build platform anyway?  In a cross compile environment, you can't 
execute the target exe anyway -- so the issue of wrappers is moot. 
Sure, I build the exe wrapper using the buildplatform compiler -- so 
*technically* you could execute the wrapper.  But that's just so the 
build will complete without a spurious failure -- you're not supposed to 
actually RUN it in a crossbuild context. If it doesn't fail exec'ing the 
shell wrapper, it will fail trying to run an other-platform binary!  In 
a cross compiler setup, wrappers -- and execution of any targetplatform 
binary -- are a complete non-issue.

Now, MAYBE in a wierd canadian cross, where build == target != host, 
there might be a problem.  We'll cross that bridge when we come to it -- 
and there's always one solution: install it (whatever "it" is) and don't 
use the wrappers.

> Now, I don't think that many people do weird cross-compile tricks, and this
> issue probably should not block a new Cygwin release of libtool, but I just
> wanted to raise the issue. I can't think of any good solution to it, either.

There's no solution because there's no problem.  cygwin-target libtool 
is only supported on posixy systems.  (I could even say that libtool, in 
general, only works on posixy systems, but there's probably some gotcha 
corner case I don't know about.)

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