This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]