Mail Archives: cygwin/2003/02/18/20:25:56
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/
- Raw text -