[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:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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
this.
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
Yes.
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
pointer.
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)?
--
Chuck
- Re: libtool 2.2.2 cross-compile to mingw problems, (continued)
- Re: libtool 2.2.2 cross-compile to mingw problems, Ralf Wildenhues, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, libtool, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, Ralf Wildenhues, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, Roumen Petrov, 2008/04/24
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/25
- Re: libtool 2.2.2 cross-compile to mingw problems, Roumen Petrov, 2008/04/28
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/26
- Re: libtool 2.2.2 cross-compile to mingw problems, Roumen Petrov, 2008/04/28
- Re: libtool 2.2.2 cross-compile to mingw problems, Charles Wilson, 2008/04/29
- Re: libtool 2.2.2 cross-compile to mingw problems, Simon Josefsson, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems,
Charles Wilson <=
- Re: libtool 2.2.2 cross-compile to mingw problems, Olly Betts, 2008/04/23
- Re: libtool 2.2.2 cross-compile to mingw problems, Simon Josefsson, 2008/04/25