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

["Max Bowsher" <maxb at ukf dot net>]

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/