Ralf Wildenhues wrote:
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. :-)
See below.
4) Generating some wrapper each time is slow.
[snip caching discussion]
Why not simply generate the second script at link time right away?
That avoids any run-time-atomicity issues, too.
Yes, I think that would work. Or, we could skip it altogether. The
attached is a modified version of a wrapper script, that:
(1) invoke the target exe directly
(2) sets all environment variables that the previous script did -- even
the ones that don't really seem relevant to cygwin|mingw, such as
BIN_SH=xpg4; export BIN_SH # for Tru64
(3) while I was messing with environment variables anyway, I added
suport for new wrapper exe options
--lt-env-set foo=bar : sets foo to bar
--lt-env-prepend foo=bar : sets foo to bar${foo}
--lt-env-append foo=bar : sets foo to ${foo}bar
No substitution is performed on bar. "foo=" is okay. "foo=bar=baz" will
set foo to "bar=baz". If no '=' is in the argument, the wrapper prints
an error message and exit(1).
Obviously, when ltmain.m4sh creates this source code, it will customize
the values of
EXE_PATH_VARNAME
EXE_PATH_VALUE
LIB_PATH_VARNAME
LIB_PATH_VALUE
For win32, the implemented algorithm ends up putting the .libs directory
into $PATH twice, but so does the current shell wrapper script.
Just as obviously, there's still quite a bit of work to do to integrate
this proof-of-concept into libtool itself. But, I was able to use it
successfully to run the target.
I haven't checked libtool --exec gdb yet, because I think I need to do
the integration work above, first, or libtool will stomp on my custom
wrapper.c...
Pursuant to the patch I just posted, putenv() would also need the same
treatment as realpath().
I'm posting this work-in-progress to solicit comments on the
implementation approach -- and if somebody with a working cross-compile
setup could modify it manually for their target and PATHs, compile it
with the $host (not $build) cross-compiler, and see if it works, that'd
be good too.
Note that I haven't tested this on mingw yet, but I don't know why it
wouldn't work. I deliberately did not #define HAVE_SETENV in the #ifdef
__CYGWIN__ section (which is what SHOULD be done) so that my cygwin test
would exercise the the same code path that mingw would, in lt_setenv().
--
Chuck