* Stop Libtool relinking against host's /usr/lib (file format not recognised)
@ 2010-12-15 7:36 Martin Panter
2010-12-15 9:12 ` Martin Panter
0 siblings, 1 reply; 6+ messages in thread
From: Martin Panter @ 2010-12-15 7:36 UTC (permalink / raw)
To: openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]
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
[-- Attachment #2: libtool-bootstrap.diff.txt --]
[-- Type: text/plain, Size: 889 bytes --]
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(-)
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}/
--
1.7.1
[-- Attachment #3: sdl-libtool-host-dir.diff.txt --]
[-- Type: text/plain, Size: 1840 bytes --]
From 7363f37b10ec83d22c06eeabdf7cfa8bf1aeb9c6 Mon Sep 17 00:00:00 2001
From: Martin Panter <vadmium à gmail.com>
Date: Thu, 2 Dec 2010 03:44:20 +0000
Subject: [PATCH] Restore libtool patch so that Libtool doesn't "relink" against host libraries
---
recipes/libsdl/files/libtool-host-dir.patch | 16 ++++++++++++++++
recipes/libsdl/libsdl-x11_1.2.14.bb | 1 +
2 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 recipes/libsdl/files/libtool-host-dir.patch
diff --git a/recipes/libsdl/files/libtool-host-dir.patch b/recipes/libsdl/files/libtool-host-dir.patch
new file mode 100644
index 0000000..b3f443f
--- /dev/null
+++ b/recipes/libsdl/files/libtool-host-dir.patch
@@ -0,0 +1,16 @@
+Stop Libtool from trying to relink against host libraries during install
+operations by using the -L/usr/lib option. Same as part of Libtool recipe's
+libtool-2.2.6b/cross_compile.patch.
+Index: SDL-1.2.14/build-scripts/ltmain.sh
+===================================================================
+--- SDL-1.2.14.orig/build-scripts/ltmain.sh
++++ SDL-1.2.14/build-scripts/ltmain.sh
+@@ -5785,8 +5790,6 @@ func_mode_link ()
+ add="$libdir/$linklib"
+ 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.
+ if test -n "$inst_prefix_dir"; then
+ case $libdir in
diff --git a/recipes/libsdl/libsdl-x11_1.2.14.bb b/recipes/libsdl/libsdl-x11_1.2.14.bb
index 5417ba3..462ea67 100644
--- a/recipes/libsdl/libsdl-x11_1.2.14.bb
+++ b/recipes/libsdl/libsdl-x11_1.2.14.bb
@@ -14,6 +14,7 @@ SRC_URI = " \
http://www.libsdl.org/release/SDL-${PV}.tar.gz \
file://sdl_bug_894_fix.patch \
file://sdl.m4 \
+ file://libtool-host-dir.patch \
"
S = "${WORKDIR}/SDL-${PV}"
--
1.7.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Stop Libtool relinking against host's /usr/lib (file format not recognised)
2010-12-15 7:36 Stop Libtool relinking against host's /usr/lib (file format not recognised) Martin Panter
@ 2010-12-15 9:12 ` Martin Panter
2010-12-15 10:10 ` Frans Meulenbroeks
0 siblings, 1 reply; 6+ messages in thread
From: Martin Panter @ 2010-12-15 9:12 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop Libtool relinking against host's /usr/lib (file format not recognised)
2010-12-15 9:12 ` Martin Panter
@ 2010-12-15 10:10 ` Frans Meulenbroeks
2010-12-22 5:42 ` Esben Haabendal
0 siblings, 1 reply; 6+ messages in thread
From: Frans Meulenbroeks @ 2010-12-15 10:10 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop Libtool relinking against host's /usr/lib (file format not recognised)
2010-12-15 10:10 ` Frans Meulenbroeks
@ 2010-12-22 5:42 ` Esben Haabendal
2010-12-22 6:56 ` Khem Raj
0 siblings, 1 reply; 6+ messages in thread
From: Esben Haabendal @ 2010-12-22 5:42 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop Libtool relinking against host's /usr/lib (file format not recognised)
2010-12-22 5:42 ` Esben Haabendal
@ 2010-12-22 6:56 ` Khem Raj
2010-12-22 8:05 ` Frans Meulenbroeks
0 siblings, 1 reply; 6+ messages in thread
From: Khem Raj @ 2010-12-22 6:56 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Stop Libtool relinking against host's /usr/lib (file format not recognised)
2010-12-22 6:56 ` Khem Raj
@ 2010-12-22 8:05 ` Frans Meulenbroeks
0 siblings, 0 replies; 6+ messages in thread
From: Frans Meulenbroeks @ 2010-12-22 8:05 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-12-22 8:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-15 7:36 Stop Libtool relinking against host's /usr/lib (file format not recognised) Martin Panter
2010-12-15 9:12 ` Martin Panter
2010-12-15 10:10 ` Frans Meulenbroeks
2010-12-22 5:42 ` Esben Haabendal
2010-12-22 6:56 ` Khem Raj
2010-12-22 8:05 ` Frans Meulenbroeks
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.