bug-libtool
[Top][All Lists]
Advanced

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

Re: libtool 2.2.2 cross-compile to mingw problems


From: Charles Wilson
Subject: Re: libtool 2.2.2 cross-compile to mingw problems
Date: Tue, 22 Apr 2008 23:39:37 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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




reply via email to

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