[Top][All Lists]

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

Re: libtool 2.2.2 cross-compile to mingw problems

From: Roumen Petrov
Subject: Re: libtool 2.2.2 cross-compile to mingw problems
Date: Mon, 28 Apr 2008 19:15:27 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080329 SeaMonkey/1.1.9

Charles Wilson wrote:
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
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().


May be for LIB_PATH_VALUE and EXE_PATH_VALUE the wrapper has to deal with relative paths to all un-installed dependent project libraries and program and may to convert them to absolute.

Let in directory $WINEPREFIX/dosdevices/ "t:" is link to /tmp/test and "z:" is link to / (root). Let current work directory (CWD) on host system is /tmp/test/XXXX. In this case after "wine cmd" CWD is T:\XXXX. Let current work directory (CWD) on host system is /tmp/YYYY, where YYYY is other than test/... . In this case after "wine cmd" CWD is Z:\tmp\YYYY.

Also I'm not sure that wrapper has to convert relative to absolute path.
If I remember well dynamic library can be loaded(method LoadLibrary) (to be checked) with relative path according following search path: program ( executable ) directory, current work directory, some system directories (%winedir% %winesysdir% other ? ), directories listed in PATH from application environment, directories listed in PATH from user environment.
Also I'm not sure what to expect if an item in PATH is relative.

May be method(function) GetFullPathName can convert relative to absolute path.


reply via email to

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