[Top][All Lists]
[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-
- mingw32 cross-compile: sys_lib_search_path setting insuffient,
Guido Draheim <=