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