Re: libtool 2.2.2 cross-compile to mingw problems

[Charles Wilson]

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:
http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00164.html
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.

--
Chuck