From patchwork Wed Dec 15 07:36:34 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Stop Libtool relinking against host's /usr/lib (file format not recognised) Date: Wed, 15 Dec 2010 07:36:34 -0000 From: Martin Panter X-Patchwork-Id: 69 Message-Id: To: openembedded-devel@lists.openembedded.org So far in my attempt to build Angstrom for my Beagle board I've found two instances where Libtool is trying to "relink" against host libraries. The first looks like it's already been fixed in the past with a patch to Libtool (recipes/libtool/libtool-2.2.6b/cross_compile.patch), but at least for me that fix is being bypassed. The patch changes the ltmain.m4sh source file but in the Libtool tarball there is already an ltmain.sh generated file which seems to be used instead. It looks like running Libtool's "bootstrap" script regenerates libtool.sh, and I've changed my code to do this according to the attached "libtool-bootstrap.diff.txt". The second instance is with SDL which seems to provide its own Libtool script. It looks like Git commit a23202736001afe7f520ef64e2431d9f994130b8 (2010-11-14) removed a patch that previously fixed my problem, so I restored the relevant bit according to the attached "sdl-libtool-host-dir.diff.txt". The original problem that led me to this was that it was failing at a Free type "install" step. (And then later for the SDL install step.) For reference, the Free type messages were something like this, paraphrased to remove the ridiculously long path names: NOTE: make LIBTOOL=arm-angstrom-linux-gnueabi-libtool DESTDIR=${IMAGE} install . . . arm-angstrom-linux-gnueabi-libtool --mode=install ${SYS}/usr/bin/install -c ${OBJS}/libfreetype.la ${IMAGE}/usr/lib arm-angstrom-linux-gnueabi-libtool: install: warning: relinking `${OBJS}/libfreetype.la' arm-angstrom-linux-gnueabi-libtool: relink: arm-angstrom-linux-gnueabi-gcc . . . -L${SYS}/usr/lib -L${IMAGE}/usr/lib -L/usr/lib -lz . . . /usr/lib/libgcc_s.so: file not recognized: File format not recognized It turned out that on my host computer (Arch linux x68_64) I indeed have this /usr/lib/libgcc_s.so file. I temporarily moved it out of the way and the relink and install worked fine. The linker seemed to be trying to use that file because of the -L/usr/lib option passed to it, and one of the changes in cross_compile.patch removes that -L/usr/lib option. -Martin >From b9300bc950b0db53467788542fe41b194afcc5bb Mon Sep 17 00:00:00 2001 From: Martin Panter Date: Wed, 1 Dec 2010 03:51:51 +0000 Subject: [PATCH] Run libtool's bootstrap to regenerate ltmain.sh from the patched ltmain.m4sh --- recipes/libtool/libtool_2.2.6b.bb | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/recipes/libtool/libtool_2.2.6b.bb b/recipes/libtool/libtool_2.2.6b.bb index a19caac..6afe92a 100644 --- a/recipes/libtool/libtool_2.2.6b.bb +++ b/recipes/libtool/libtool_2.2.6b.bb @@ -13,6 +13,10 @@ FILES_libltdl = "${libdir}/libltdl.so.*" FILES_libltdl-dev = "${libdir}/libltdl.* ${includedir}/ltdl.h" FILES_libltdl-dbg = "${libdir}/.debug/" +do_configure_prepend () { + ./bootstrap +} + do_stage () { install -d ${STAGING_INCDIR}/libltdl install -m 0644 libltdl/ltdl.h ${STAGING_INCDIR}/