Patchwork Stop Libtool relinking against host's /usr/lib (file format not recognised)

login
register
mail settings
Submitter Martin Panter
Date Dec. 15, 2010, 7:36 a.m.
Message ID <AANLkTimMz5m27fxSGVw-YyOAH2=Wbye2Ug71mZ9t+py1@mail.gmail.com>
Download mbox | patch
Permalink /patch/69/
State Not Applicable
Headers show

Comments

Martin Panter - Dec. 15, 2010, 7:36 a.m.
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 <vadmium à gmail.com>
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(-)
Martin Panter - Dec. 15, 2010, 9:12 a.m.
On 15/12/2010, Martin Panter <vadmium+floss@gmail.com> 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
Frans Meulenbroeks - Dec. 15, 2010, 10:10 a.m.
2010/12/15 Martin Panter <vadmium+floss@gmail.com>:
> On 15/12/2010, Martin Panter <vadmium+floss@gmail.com> 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
>

Thanks.
As the reporter of the gettext problem it at least gives me a
suggestion on where to look.

Frans
Esben Haabendal - Dec. 22, 2010, 5:42 a.m.
On Wed, 2010-12-15 at 11:10 +0100, Frans Meulenbroeks wrote:

> As the reporter of the gettext problem it at least gives me a
> suggestion on where to look.

Any news on resolving this for gettext?

/Esben
Khem Raj - Dec. 22, 2010, 6:56 a.m.
On (22/12/10 06:42), Esben Haabendal wrote:
> On Wed, 2010-12-15 at 11:10 +0100, Frans Meulenbroeks wrote:
> 
> > As the reporter of the gettext problem it at least gives me a
> > suggestion on where to look.
> 
> Any news on resolving this for gettext?
> 
I think it was wrong usage of libtool 2.4 it should be workin now I think

> /Esben
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Frans Meulenbroeks - Dec. 22, 2010, 8:05 a.m.
2010/12/22 Khem Raj <raj.khem@gmail.com>:
> On (22/12/10 06:42), Esben Haabendal wrote:
>> On Wed, 2010-12-15 at 11:10 +0100, Frans Meulenbroeks wrote:
>>
>> > As the reporter of the gettext problem it at least gives me a
>> > suggestion on where to look.
>>
>> Any news on resolving this for gettext?
>>
> I think it was wrong usage of libtool 2.4 it should be workin now I think
>

I'm not sure if I would qualify using libtool 2.4 without the sysroot
support as "wong usage".
Anyway, if you use oe head or libtool 2.4 with sysroot support enabeld
the problem is gone.
Not that all my libtool problems are gone though...

Frans

Patch

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}/