I'd like to submit a bug that shows up while cross-compiling multiple packages under Gentoo Linux for the ARM target platform. There is currently a bug report in Gentoo's bugzilla system (https://bugs.gentoo.org/show_bug.cgi?id=521184)
and I also have been advised to contact you, upstream. I have tried to understand and investigate libtool enough to come up with a patch.
So far, packages that didn't compile are glib-2.40.2 and glib-2.42.2, alsa-lib-1.0.29. I still am not done with compiling all the packages I need though. My findings are that libtool adds lib directories to look for dynamic libraries the current project depends upon. From what I've seen of libtool's code, it adds and reorders directories as it finds them. Troubles come when cross-compiling and /usr/lib gets added to the list, which causes libtool bypass legit directories, e.g. /usr/armv7a-hardfloat-linux-gnueabi/tmp/usr/lib (something like this where the target binary file to install resides).
Here's one build log for glib-2.40.2:
libtool: warning: relinking 'libgmodule-2.0.la'
libtool: install: (cd /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.40.2/work/glib-2.40.2-.arm/gmodule; /bin/sh "/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.40.2/work/glib-2.40.2-.arm/libtool" --tag CC --mode=relink armv7a-hardfloat-linux-gnueabi-gcc -fvisibility=hidden -O2 -pipe -fomit-frame-pointer -Wl,-Bsymbolic-functions -Wl,--export-dynamic -version-info 4002:0:4002 -export-dynamic -Wl,-O1 -Wl,--as-needed -o libgmodule-2.0.la -rpath /usr/lib libgmodule_2_0_la-gmodule.lo -ldl ../glib/libglib-2.0.la -inst-prefix-dir /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.40.2/image/)
libtool: relink: armv7a-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/libgmodule_2_0_la-gmodule.o -ldl -L/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.40.2/image//usr/lib -L/usr/lib -lglib-2.0 -lpthread -O2 -Wl,-Bsymbolic-functions -Wl,--export-dynamic -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,libgmodule-2.0.so.0 -o .libs/libgmodule-2.0.so.0.4002.0
/usr/lib/libdl.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
libtool: error: error: relink 'libgmodule-2.0.la' with the above command before installing it
Makefile:1659: recipe for target 'install' failed
make: *** [install] Error 2
See the above GCC parameter -L/usr/lib. This is the one that messes up cross-compiling because it's passed last, after -L/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.40.2/image//usr/lib.
After digging the code in libtool I found out the problem lies somewhere around line 8888. Here's my suggested fix:
--- old/libtool 2015-05-05 13:50:50.340341464 +0200
+++ new/libtool 2015-05-05 13:49:44.448340141 +0200
@@ -8888,7 +8888,10 @@
if test -n "$inst_prefix_dir"; then
case $libdir in
- func_append add_dir " -L$inst_prefix_dir$libdir"
+ # EDIT: Remove $libdir search path on cross-compiled environment to
+ # avoid "file format not recognized" errors. If $inst_prefix_dir is
+ # given, don't bother adding $libdir to the dependency search path.
After applying this patch while emerging a package that failed the installation phase on Gentoo, the package successfully installs and runs. I tried suggestions from Gentoo maintainers, namely run the compile/install phase with environment variable EXTRA_CONF="--with-sysroot=yes" but that did not prevent the installation phase from failing. I have not tried to run the modified libtool against *all* my installed packes, just a few of them, but it appeared to work normally when the target platform is equal to the compiling host's.
I am joining the complete build log for glib-2.40.2 and my libtool patch.