I've been compiling programs with Open embedded and came across an
issue that has apparently been around for a long time. I think the
symptoms have been described many times before; see list of links
further down. But briefly, when using Libtool to cross compile and
install programs into a target "staging" file system rather than
directly into the build host's file system, I found Libtool would do a
"relink", which would pass a "-L/usr/lib" (host directory) option to
GCC, which would then fail with a message like this:
/usr/lib/libgcc_s.so: file not recognized: File format not recognized
I understand earlier versions of GCC's linker would warn about this
but continue and presumably find the right library with the right file
format in a different directory. These days GCC just aborts instead.
I suggest the attached patch as a solution. I think this problem has
always been present, ever since the "installation prefix" (target
staging) feature was added in the following commit:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=d2c4f8f8fc04e4fe282953800b913dc7c5595c59
My patch simply avoids passing the host directory to GCC when the
directory with the installation prefix is also passed. Previously it
would pass both directories.
== Existing alternative patches
Original patches kicking around in Open embedded just blindly delete
the "add_dir" assignment. See the middle hunk of the three hunks in
this patch:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.2.6b/cross_compile.patch?id=release-2010.12
However I suspect that is only valid when cross compiling and not
installing directly to the target root filesystem (without a
"prefix").
There's also a newer one for a "sysroot" feature:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath.patch?id=release-2010.12
I haven't learnt what this feature is, and I think this change doesn't
apply if the "sysroot" feature is not used.
== Other reports of this issue that I came across:
"Relink with a DESTDIR install mistakenly links against old installed
libraries rather than those in DESTDIR"
http://savannah.gnu.org/support/?107416
My initial ramblings about this issue on the Open embedded mailing list:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-December/027868.html
"Issue with Libtool when cross-compiling". See reply from Richard
Purdie referring to patches from Poky.
http://lists.gnu.org/archive/html/libtool/2010-02/msg00000.html
'Re: Issues with "relink" and cross-compilation'. Again with reply
from Richard Purdie.
http://lists.gnu.org/archive/html/libtool/2010-07/msg00018.html
"Relinking and cross-compiling"
http://lists.gnu.org/archive/html/libtool/2010-03/msg00013.html
"Can't cross-compile with same libdir as the host one"
http://lists.gnu.org/archive/html/bug-libtool/2010-10/msg00036.html
Found a paragraph added to documentation which might be related to my issue:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=e34d7507d63faeb4ddaa75b1ecf87ee5aad1aa37
To me that suggests cross compiling many programs would generally only
be possible by installing third-party target architecture libraries
into the host file system. (I imagine this is kind of how Scratchbox
works.)
-Martin
Don't search host directory during "relink" if $inst_prefix is provided
Index: libtool-2.4/libltdl/config/ltmain.m4sh
===================================================================
--- libtool-2.4.orig/libltdl/config/ltmain.m4sh
+++ libtool-2.4/libltdl/config/ltmain.m4sh
@@ -6122,12 +6122,14 @@ func_mode_link ()
fi
else
# We cannot seem to hardcode it, guess we'll fake it.
- add_dir="-L$libdir"
- # Try looking first in the location we're being installed to.
+
+ # Default if $libdir is not relative to the prefix:
+ add_dir="-L$libdir"
+
if test -n "$inst_prefix_dir"; then
case $libdir in
[\\/]*)
- func_append add_dir " -L$inst_prefix_dir$libdir"
+ add_dir="-L$inst_prefix_dir$libdir"
;;
esac
fi
