[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: Charles Wilson
Subject: Re: libtool 2.2.2 cross-compile to mingw problems
Date: Tue, 29 Apr 2008 21:00:04 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

Roumen Petrov wrote:
Please find attached archive lt-2.2.2-mingw-mlib.tgz .
It contain test case with an application that call functions from other two project libraries:
- library libfoo1 in subdirectory lib1;
- library libfoo2 in subdirectory lib2;
- program foo in subdirectory appl.

The file lt-mdemo.c.diff from archive is difference to you wrapper script.
To get exit code from real program we has to use spawnvp(P_WAIT,....

Right. In ltmain.sh (func_emit_cwrapperexe_src), there is already support for using spawnv instead of exec, if $host = mingw. So, you should be able to get the exit status. Now, about the stdout being printed AFTER the program exits and you're already back at the prompt -- that's an MSYS/bash issue that I've noticed even on native mingw/MSYS.

Although the test succeed with slash(/) in path I think that on host it will fail due "./" in paths. I think that winapi work with slashes in path only if they do'nt appear after dot.

The patch to ltmain.m4sh that I posted here:
already converts '/' to '\\' when $host = mingw.

Also I note that path to second depended un-installed library is absolute instead relative:
/bin/sh ../libtool --tag=CC --mode=link i386-mingw32msvc-gcc -g -O2 -no-undefined -avoid-version -o foo.exe foo.o ../lib2/libfoo2.la libtool: link: i386-mingw32msvc-gcc -g -O2 -o .libs/foo.exe foo.o ../lib2/.libs/libfoo2.dll.a /usr/local/...../1/lt-2.2.2-mingw-mlib/lib1/.libs/libfoo1.dll.a -L/tmp/test/pkg/lt-2.2.2-mingw-mlib/lib

Also the path to libdir is added but may be this is fine.
In my environment the path to the library installation directory is not visible under emulation.

Yes, that's why I had to use the `cmd //c echo $1` trick instead of `cd $1 && pwd -W`. The latter version doesn't work if $1 doesn't exist -- and if you're doing a DESTDIR install, or running one of the tests, $DESTDIR$prefix/lib might not yet exist.

With the posted patch, if `cmd //c echo $1` fails to convert $1 to an appropriate $host path, libtool will print a warning, but continue.

Also, note that we don't see relative paths in practice. In func_emit_cwrapperexe_src(), the variables $temp_rpath and $dllsearchpath that we want to add to $PATH, are already canonicalized to absolute, IIRC. [And the path to the target is made absolute by find_executable()]

Thanks for testing.


reply via email to

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