[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: Fri, 25 Apr 2008 00:29:31 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080329 SeaMonkey/1.1.9

Ralf Wildenhues wrote:
* address@hidden wrote on Thu, Apr 24, 2008 at 04:15:26PM CEST:
On Thu, 24 Apr 2008 07:50:22 +0200, "Ralf Wildenhues" said:

We have freedom to check $build and use its shell interpreter for
executing uninstalled scripts.
So, for cross-compile cases where $host = cygwin|mingw, but ($build !=
cygwin && $buikd != mingw), we could
a) use the current non-win32 schema: no .exe wrapper, just a shell

This part sounds good.

b) name that shell wrapper "foo.exe"

Dunno.  I still don't grasp binfmt_support and wine semantics
sufficiently to be able to say something about this.

Alternatively, for $host=cygwin|mingw, make the executable wrapper
capable of manipulating the environment of the child process, and
directly exec the target executable.  Would libtool --exec gdb work in
this case, and allow to debug the actual target exe?

Dunno, but it would be good if it worked.  :-)

4) Generating some wrapper each time is slow.  Not a show-stopper,
but a usability regression.  I have forgotten why a second wrapper
script, once generated, cannot remain below $objdir, but is removed
each time again.
We had talked about this at the time. The problem is, if you 'cache' the
script, you then have to determine if the script is in sync with the
wrapper executable.  Which probably means stat'ing both and comparing

Why not simply generate the second script at link time right away?
That avoids any run-time-atomicity issues, too.


Looking into script generated by wrapper executable I identify some other commands that born script try to execute: /usr/bin/sed, ls and pwd. So in emulated environment we must install those commands to and to pass to the wrapper their location TARGETSED TARGETLS TARGETPWD....
It is no so intuitive. It is too complex.

Now I'm thinking about possibility in cross-compilation case libtool to create wrapper executable. This binary has to set environment in way specific to the emulator(may be we can specify it at configure time) and to try run directly real host executable from .libs directory.
I don't know how portable is as example execve.
Emulator can be wine or something specific for a hardware device.

So the shell script located in build dir run wrapper host-progpram in emulator. The wrapper program (it can be located in .libs directory), set environment (PATH,etc.) and exec real program from same directory (i.e. libs).


reply via email to

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