Summary: | dev-libs/libical - armv7a-hardfloat-linux-gnueabi-ld: /usr/lib/libpthread.a: could not read symbols: File format not recognized | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | nikarul |
Component: | [OLD] Library | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | vincent.cadet |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build log
build.log Workaround for ebuild (patch) |
Description
nikarul
2013-02-09 03:39:20 UTC
The build log you attached doesn't seem to suggest that - you terminated the build process it seems. Could you attach a complete build log, please? Created attachment 338428 [details]
build.log
Additional investigation revealed this is an issue with the make install step. It appears to be an issue with make DESTDIR=<dir> install and libtool attempting to relink the library with native libraries as a result. I found a discussion regarding this issue here: http://lists.gnu.org/archive/html/libtool/2010-02/msg00000.html It also appears not to be specific to libical, as I'm now seeing a similar issue attempting to cross compile gstreamer. Created attachment 338656 [details, diff] Workaround for ebuild (patch) I found a work around for the issue, based on the information I found on this webpage: http://www.metastatic.org/text/libtool.html As shown in the attached patch, I changed the install part of the ebuild to modify the *.la files from libical to point at the install root used when packaging. This allows the build to succeed and since the ebuild does not install the *.la files, there's no issue with them being incorrect in the SYSROOT. I've only tried in a Portage overlay I use when cross compiling, so this may be undesirable (or even broken) for native builds. I have the same issue cross-compiling libical (on which bluez depends) for armv7a-hardfloat-linux-gnueabi. Shall I attach my build log, too? Just to mention nikarul's trick (from comment #4) did it although I recon it's just a workaround as from what I understand elibtoolize should take care of this issue. Today I compiled libical-1.0.1 for the ARM target and it installed correctly. This is a WORKSFORME status as far as I'm concerned. Thanks for the feedback, I guess we can assume it's fixed in libical-1.0.1 then. |