Re: libtool 2.2.2 cross-compile to mingw problems

[libtool]

On Thu, 24 Apr 2008 07:50:22 +0200, "Ralf Wildenhues" said:
> 1) Cross compiling from GNU/Linux to MinGW currently needs a MSYS shell
> on the $host system.  That is a usability regression which should be
> eliminated if at all possible.

Ack.

> 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
b) name that shell wrapper "foo.exe"

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?

> 2) Depending upon
>   - whether the user specified '-o foo' or '-o foo.exe'
>   - other details (such as whether we link against an uninstalled
>     library at all)
> we may be generating 'foo' or 'foo.exe', esp. with a cross compile.
> This is unfortunate.  I'm not sure what the best strategy is.
> Non-automake users may have different needs than automake users.
> One solution may be just to adjust the documentation (but not doing
> anything here is wrong!)

Yikes. Maybe the 'alternative' strategy above is actually easier than
dealing with all that mess.

> 3) Independently of w32: we need to make generation of both binary and
> shell wrappers atomic.  Rationale: when the user executes two instances
> of the uninstalled wrapper, we must not fail.  See here for more
> information: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752>.

Yes; see below.

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

Which is unreliable for $build = win32, given the 2 second granularity
of FAT32. NTFS is better, but we can't assume that.

Hmm. If the wrapper exe directly execs the target, we eliminate this
problem too: it solves the multiprocess case, the synchronization issue,
AND the slowness. Plus, it saves a number of fork/execs...the
interstitial shell, but also any external commands invoked within the
current wrapper script.

Downside: it makes the 'allow wrapper [script] to set user-determined
environment variables' patch twice as much work.

--
Chuck