This is the mail archive of the
mailing list for the Cygwin project.
Re: [avail for test] libtool-devel-20030216-1
Max Bowsher wrote:
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.
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.
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.
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.)
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html