bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




reply via email to

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