Simon Josefsson wrote:
Charles Wilson <address@hidden> writes:
How is this intended to work? You can't execute bash scripts under
Windows nor Wine, as far as I know.
Yes and no. You need some win32 shell installed in your Wine
environment. (For native win32 builds, this is no problem: if you are
running libtool, you have a shell).
That seems to be a regression from libtool 1.5.x: I haven't needed
anything but Wine itself to build and run programs before. Libtool
1.5.x used a shell script which used the native shell, rather than
requiring a shell for the target.
It probably is a regression, but it's not one that can be easily fixed.
The reason we use a binary wrapper is as follows (taken from
http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00050.html,
and rewritten slightly):
In earlier libtool, on cygwin/mingw, the following files are created:
foo.exe -- a [win32] wrapper executable, that launches...
foo -- a wrapper scripts, which sets env vars and launches...
.libs/foo.exe -- the actual target executable
The reaons for this old arrangement was we needed a '.exe' in the actual
object directory, so that 'make' would understand that target$(EXEEXT)
had already been built. Otherwise, 'make install' would always relink,
'make check' would relink, and sometimes pathological cases would get
into an infinite relinking loop.
However, because we still had the original wrapper script -- and there
was nothing win32-specific about it; it's just a simple sh script --
cross-compiler folks just ignored the target$(EXEEXT) wrapper, and
invoked the shell wrapper directly.
However, the presence of both foo and foo.exe in the same directory
causes some problems with coreutils/shells' "autodetect .exe's" logic
under "native" MSYS and "native" Cygwin. And it's downright unusable
when the cygwin "transparent_exe" option is active.
So, eventually we decided to eliminate ./foo entirely on these
platforms, and rely entirely on ./foo.exe and .libs/foo.exe (with
perhaps some other files in .libs/)
Putting a shell-script "foo" back into the main directory would
re-impose these "autodetect .exe" issues on the native platforms.
There IS an option that will work on cross-compile hosts which are not
confused by the presence of foo.exe and foo in the same directory (it's
a bit ugly):
$ wine ./foo.exe --lt-dump-script |\
sed -e
's/^WRAPPER_SCRIPT_BELONGS_IN_OBJDIR.*$/WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no/'
> ./foo
And now you can use foo as you like. Simpler, but still awkward at present:
$ wine ./foo.exe --lt-dump-script > ./.libs/foo
$ .libs/foo
If it hasn't been clear, I'm cross-compiling from debian x86 to mingw.
*) lt_newargv0=$lt_newargv0.exe ;;
esac
;;
* ) lt_newargv0=$SHELL ;;
esac
Is the result of this operation printed anywhere, during ./configure?
No.
export TARGETSHELL="C:\\Util\\gnuwin\\bin\\sh.exe"
export TARGETSHELL="C:\\msys\\1.0\\bin\\sh.exe"
*before* building your project.
This seems like a reasonable workaround, but it seems the \ escaping
didn't work out well. I got plenty of errors during build:
Other responders in this thread have noted issues with the quoting style
(my example was wrong). However, in the end everybody seems to run into
the same issue: the ultimate command seems to fail.
However, I'm not sure my sh.exe is working properly:
address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ wine
C:/MinGW/bin/sh.exe --help
Wine failed with return code 1
address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$
And that, I don't understand. It's not just some weird issue with the
bash stdout going to an MSYS-emulated pty, that has trouble hooking up
to the wine-emulated Win32 Console Handle, that has trouble hooking up
to the linux pty -- because even if all that were true, bash --help
should exit with 0, and wine should propagate that success code. Even
if you can't see stdout from win32-bash.
Rouman Petrev posted a bug report to the mingw-users list; we'll see
what kind of response that generates. But for now, you should be able
to use the --lt-dump-script workaround for all your wrapped executables,
and then just use the wrapper *script* as you are used to.
--
Chuck
bootstrap.sh.gz