[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool 2.2.2 cross-compile to mingw problems

From: Roumen Petrov
Subject: Re: libtool 2.2.2 cross-compile to mingw problems
Date: Wed, 23 Apr 2008 23:02:52 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080329 SeaMonkey/1.1.9

Charles Wilson wrote:
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 |\

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 ;;
  * ) lt_newargv0=$SHELL ;;

Is the result of this operation printed anywhere, during ./configure?


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

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.


Ok it seems to me reasonable to dropout old behaviour to avoid problem with "transparent_exe" option on build platform. Is possible during configure time to detect whether "transparent_exe" option is switched "on" ?

Other question is presence of any wrapper scripts. I include my test case (see attached file bootstrap.sh.gz). The make create: test.exe .libs/test_ltshwrapper .libs/test.exe and etc (not important
to report).
The test.exe create .libs/test_ltshwrapperTMP .

The script .libs/test_ltshwrapper seems to me useless due errors:
$ sh .libs/test_ltshwrapper
.libs/test_ltshwrapper: error: `..../.libs/.libs/test.exe' does not exist
This script is just a wrapper for test.exe.
See the libtool documentation for more information.
Why this script(.libs/test_ltshwrapper) is created by make (...libtool --tag=CC --mode=link ...) ? Why is not created with WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=yes and test.exe just to run it? If is possible to detect platform with "transparent_exe" why libtool do not create (on other build platforms) wrapper scrip as before ? In this case test.exe can try to run it directly without to create .libs/<PROGRAM>_ltshwrapperTMP.

Also I'm familiar with other disadvantage of old behaviour: the path set by wrapper script is overwritten by wine. To overcome this limitation, when project create libraries in different paths, I add a specific directory the the wine path and before to run tests I purge it and populate project libraries into it. But for some projects this is not issue.


Only for the protocol the difference between wrapper scripts (as Charles note):
-- .libs/test_ltshwrapperTMP   2008-04-23 00:51:24.000000000 +0300
+++ .libs/test_ltshwrapper      2008-04-23 21:43:39.000000000 +0300
@@ -80,7 +80,7 @@

    # Usually 'no', except on cygwin/mingw when embedded into
    # the cwrapper.
    if test "$WRAPPER_SCRIPT_BELONGS_IN_OBJDIR" = "yes"; then
      # special case for '.'
      if test "$thisdir" = "."; then

Attachment: bootstrap.sh.gz
Description: application/gzip

reply via email to

[Prev in Thread] Current Thread [Next in Thread]