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