On 15/12/2010, Martin Panter <[email protected]> wrote: > 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.
PS: I think the same issue might be the cause of the problem mentioned in the "gettext libtool ARM issue" thread. It also looks like it's running a local version of Libtool, a -L/usr/lib option gets passed to GCC, and then the "File format not recognized" error. http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-December/027797.html > -Martin _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
