libtool
[Top][All Lists]
Advanced

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

mingw32 cross-compile: sys_lib_search_path setting insuffient


From: Guido Draheim
Subject: mingw32 cross-compile: sys_lib_search_path setting insuffient
Date: Sun, 22 Jul 2001 21:58:12 +0200

I've been using the precompiled linux->mingw32 packages
from libsdl.org/Xmingw32 - which has the advantage of
installing quite a few importlibs in its libs-directories.
(for my project, it even has i386-mingw32msvc/libz.a).

The dll of my project does need some function from a
a lib installed with the gcc - the libtool has support
for this scheme as it uses "$CC --print-search-dirs",
then greps it for the "libraries:" line, and puts it
into sys_lib_search_path.

Now, let's guess all we need is a line saying "-lz"
to resolve functions of my dll against libz.a. The
gcc knows its own libs so it could link to it anyway,
it is the gcc's sys_lib directory after all.

Well, this is only part of the truth, as for the
creation of dlls, we need to tell -no-undefined as
an option to the linker, which will provoke libtool
to actually search the libpath for the real libfile
*before* running a gcc-link command. Otherwise, if
it can't be found, the link-step fails altogether.

So far, so good - but there is a bug. The search is
done in the "file_magic)" part, and the section
contains a for-loop over all library-directories
in which it potentially find the real libfile. This
one reads:

for i in $lib_search_path $sys_lib_search_path $shlib_search_path; do

looks good? No, it does not - the cross gcc that I've
been using returned something like:

libraries:/usr/local/bin/../lib/gcc-lib/i386-mingw32msvc/2.95.2/:/usr/local/bin/../lib/gcc-lib/:...........

that means it returned a dirpath where directories are seperated
with ":". The $sys_lib_search_path above has this line, unmodified
with respect to the dir-seperator !!!!!! The effect is, that one 
of checks for the real libfile reads "xxx/lib:yyy/lib/libz*" 
which can not be found (there is no "xxx/lib:yyy/lib" directory)

I tried to add a line just before the libfile-search loop, saying
sys_lib_search_path=`echo $sys_lib_search_path | sed 's,:, ,'g`
and then it works - the libz is found in its syslib directory,
and the rest of the dll-link succeeds.

As far as I can see, this bug affects about all versions of 
libtool that I have on my system for tests - it's probably
coming of the time the dll-link feature was added to libtool.
Which makes me wonder if it had been working any time before 
possibly due to different behaviour of the gcc -print-search-dirs?

The other question is now - where to fix it? My guess would be
to adapt libtool.m4 where "$CC --print-search-dirs" is used
and which overrides the sys_lib_search_path_spec. Adding a
tr-colon-to-space should help it once and for all, but it may
need to check the build-system being unixish w.r.t to its
path-separator, right?

Anyway, it breaks crosscompiling for me, and it may be the
reason others have never been able to create a dll where
indeed it is possible even now - when patching current libtool.

does everyone agree that this is a bug, needs to be fixed,
can fixed like suggested, and included soon in a libtool dist?

cheers,
-- guido                               http://guidod.4t.com
31:GCS/E/S/P C++$++++ ULHS L++w- N++@  d(+-) s+a- y++ 5++X-



reply via email to

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