I'm still tracking a problem where libtool adds native libraries to
the link when cross-compiling. I've upgraded to 1.5.20, just to make
sure that this hasn't yet been fixed. Here's what I've found.
There appear to be two factors at play. First is the postdeps:
# Dependencies to place after the objects being linked to create a
# shared library.
postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s"
This is where the explicit inclusion of libstdc++ is entering into the
link. The second,
# The library search path used internally by the compiler when linking
# a shared library.
compiler_lib_search_path="-L/usr/lib/gcc-lib/i486-linux/3.3.5
-L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.."
is where the path to native libraries is being referenced such that
libtool can search them.
Then, comes this:
if test "$linkmode" = lib; then
libs="$predeps $libs $compiler_lib_search_path $postdeps"
which explicitly adds $postdeps and $compiler_lib_search_path to the
link. The result is that /usr/lib/libstdc++.la is added to the
library dependency list of an .la file. Later, when an application
links with this library, the link fails because the wrong architecture
is being used.
So, the question is this. Do I need to build a special version of
libtool for cross compiling which is separate from the version used to
build native packages?
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
