Re: libtool 2.2.2 cross-compile to mingw problems

From:

Ralf Wildenhues

Subject:

Re: libtool 2.2.2 cross-compile to mingw problems

Date:

Thu, 24 Apr 2008 19:30:27 +0200

User-agent:

Mutt/1.5.17 (2008-03-09)

* 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