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: <001301c2d7b5$cadc8fe0$78d96f83@pomello>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: <cygwin AT cygwin DOT com>
References: <3E519478 DOT 6050108 AT ece DOT gatech DOT edu> <007f01c2d797$5fb5d1e0$78d96f83 AT pomello> <3E52D4F7 DOT 5060803 AT ece DOT gatech DOT edu>
Subject: Re: [avail for test] libtool-devel-20030216-1
Date: Wed, 19 Feb 2003 01:25:30 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Charles Wilson wrote:
> 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.

I do - Cygwin!

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

But it does, 99.9% of the time, and I'm very reluctant to install a second
POSIX emulator, when Cygwin works very nicely.

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

The exe in question is built, then used to build a .c source file, which is
then built.

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

Of course not - It uses Cygwin bash.

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

The problem arises from using the trickery of a configure like this:

CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin'
./configure --build=mingw32 --host=mingw32

OK, I'm lying to configure. But it works - or it did.

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

Which is why I lie to configure and don't say --build=cygwin --host=mingw32.
For the special case of a cygwin -> mingw cross-compile, the built exes will
run on the building machine, but autotools don't know that.


An acceptable kludge occurs to me - I can sed out -mno-cygwin from the line
used to compile the wrapper exe. But I still can't think of any way neat
enough for eventual inclusion in libtool.


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/