[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: Charles Wilson
Subject: Re: libtool 2.2.2 cross-compile to mingw problems
Date: Wed, 23 Apr 2008 19:55:18 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

Simon Josefsson wrote:>
Sure, and I have no problem with dropping the shell script 'foo'.  I
don't think I have been using it, and if I were, that would be a bug I
should fix (I should call foo.exe instead).  I am primarily wanting to
get 'make check' produced by Automake to work (and it calls foo.exe and
never uses the 'foo' shell script).  I am sorry if I wasn't clear about

Sorry, I was confused by the recent discussion about setting env variables in the wrapper script -- that was more about end users trying to manually run uninstalled applications.

As far as I understand the new approach, it is:

  foo.exe - a [win32] wrapper executable, that launches...
  $TARGETSHELL .libs/foo_ltshwrapperTMP -- which sets env vars and launches...
  .libs/foo.exe -- the actual target executable


Requiring a working bash.exe on the target host seems to me be the
problematic part, and that is a regression over libtool 1.5.x.  What if
you are cross-compiling to a platform that doesn't have a POSIX shell?

That would be a win32 platform of some kind, because otherwise none of this stuff applies. So, are we talking about WinCE or something?

Implementing what the shell script does directly in foo.exe seems like a
better solution to me,

Yes, it is. It's not /that/ hard, either, just tedious to code, and it was certainly NOT something I wanted to work on while waiting for libtool-2.2 (and thereby delaying libtool-2.2 even longer).

and seems to be what you suggest too.  I'll try
to get some work-around working with libtool 2.2, or revert to libtool
1.5, meanwhile

There's another option.

[snip --lt-dump-script workaround]

That works in the sense that the application starts, thanks for the

However, I'm not sure how it solves my problem, which is to get 'make
check' to work.  Automake still invokes foo.exe, and that fails with
libtool 2.2.

Right. I was thinking manual invocation.

Hm.  Possibly the following would work for me:

./foo.exe --lt-dump-script > tmp
mv tmp foo.exe

Yes, that appears to work.

Really? I would have thought you'd need to sed the WRAPPER_SCRIPT_BELONGS_IN_OBJDIR value to "no" in that case, since your wrapper script 'tmp->foo.exe' is /not/ in .libs.

The remaining (and likely the biggest)
problem is to integrate this with the automake 'make check'
infrastructure.  Possibly I could use a TEST_ENVIRONMENT hook, but it is
ugly.  Other ideas?

Yes. See below.

Rouman Petrev posted a bug report to the mingw-users list; we'll see
what kind of response that generates.

Great.  I hope we can solve it this way.  I liked your TARGETSHELL
work-around better.

Earnie seems to think it *is* a problem with the pty emulation. *If* so, it's a new symptom of an old, and known problem with both cygwin and msys...native progs (other than cmd.exe itself) have difficulty receiving the output from cygwin/msys stdout -- which is an emulated pty and NOT a Win32 ConsoleOutputHandle (or whatever).

So *if* that's the problem, it's probably unfixable without major surgery to cygwin/msys/wine. But if not, then perhaps it can be fixed. But somebody's going to have to dig very deep to figure out which. (Geez: two different OS's [linux, win32], two different emulation environments [wine, msys|cygwin], all chained together, Debug THAT.)

But maybe we don't have to.

I'm using automake 'make check' which is not calling the wrapper script,
so this doesn't work.

right. so, on a cross compile where ( $build != cygwin && $build != mingw ), why do we need a native win32 wrapper executable? Oh, right: because $EXEEXT is always going to be .exe if $host = some_win32.

Well, as you point out, there's no reason on a !win32 $build, that 'foo.exe' must be a binary executable. It can be a shell script.

So maybe if $host is win32, but $build is !win32, we do the following:
  (1) no cwrapper
  (2) create the wrapper script as foo.exe
this is a fairly intrusive change, and will take a while to get correct. But I think it has possibilities of satisfying all users.

The only issue left would be this, in the wrapper script;

    exec "$progdir/$program" ${1+"$@"}

How would that work, if what you really want is

    exec "wine" "$progdir/$program" ${1+"$@"}

something like this?

    exec $MY_EMULATION_INVOKER "$progdir/$program" ${1+"$@"}

But surely /that/ problem has been solved for other cross-compile setups, where your target is in some emulation environment or on some remote machine? How did it work, before (WAY before, back when there WAS no c_wrapper at all)?


reply via email to

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