Re: libtool 2.2.2 cross-compile to mingw problems

[Roumen Petrov]

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
> > wrapper
>
> 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
> > timestamps.
>
> Why not simply generate the second script at link time right away?
> That avoids any run-time-atomicity issues, too.
>
> Cheers,
> Ralf

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).


Roumen