The libtool adds various directories to the library search patch during the relink phase. This behaviour makes cross-compilation life very hard. Reproducible: Always Steps to Reproduce:
Created attachment 184826 [details, diff] Libtool fix Add the directory of the target instead of the host to the search patch.
Created attachment 184827 [details, diff] Patch for the libtool ebuild This uses the libtool patch in the ebuild.
libtool changes get propagated to all packages that use libtool, even the ones outside of the tree. changing it like this will break things.
Would it help to only patch that in for cross-compilation? What kind of patch would have a chance to get accepted by you? As I said, this fixes alot of problems seen during cross-compilation for alot of packages, so please give me at least a chance to find a proper solution.
relying on variables that only exist on Gentoo (or inside of portage) will not work. that is what elibtoolize is for. if you're interested in a general/correct solution, cross-compile / DESTDIR threads have been posted to the libtool mailing lists multiple times http://lists.gnu.org/archive/html/bug-libtool/
Created attachment 184947 [details, diff] Improved libtool fix This patch uses native libtool variables to make the libtool cross-compile aware during the relink phase.
hmm, i like that patch. how many packages have you tested with it ? it'll only show up if you emerge libtool with that patch, and then emerge a package that runs libtool during src_unpack to regenerate autotool files ...
Yeah, exactly. I tested this version of libtool against emerging a base system using our Openmoko profile: http://overlays.gentoo.org/proj/embedded/browser/openmoko/trunk/openmoko-target/profiles/openmoko It is now possible to cross-compile all those packages (ok some of them need additional patches) without specifying -L$ROOT/usr/lib etc. as LDFLAGS. A good example of a package requiring the patch is libusb. Without the libtool patch it fails during the relink phase. However, the patch here is somehow complementary to the libtool.eclass fix.
Any news on this? SpanKY do you want me to modify the patch or something?
Any progress on this? The gap between crossdev and libtool causes a lot of headaches when doing a cross compile.
*** Bug 272089 has been marked as a duplicate of this bug. ***
*** Bug 275462 has been marked as a duplicate of this bug. ***
*** Bug 273910 has been marked as a duplicate of this bug. ***
I hit this same problem cross-compiling libusb and gdbm for the ARM similar to what others have reported (and duped to this bug). Anyway we can get this patch applied to the libtool ebuild?
Created attachment 218371 [details, diff] new ELT-patches/cross/link-ROOT This seems to solve the problem in dev-libs/mpfr and dev-libs/ppl. Please test.
Comment on attachment 218371 [details, diff] new ELT-patches/cross/link-ROOT libtool has to use POSIX shell syntax. things like [[ ... ]] are bashisms.
Any progress?
Created attachment 264231 [details, diff] cross-compile link root patch I rewrote P. Levine's patch. I hope it now will comply to POSIX. BTW there are packages, which ship ltmain.sh in source and for successful cross-compiling this patch is needed. Should I open bug report for each of this package with patch?
Comment on attachment 264231 [details, diff] cross-compile link root patch not really. not all packages using libtool need this. if there is a package which you *know* needs it, then opening a bug so that it calls `elibtoolize` would be fine. but that can only be done once this gets added to the ELT dir. i dont think assuming ROOT makes sense. what i've always done is simply delete the -L path. - add_dir="-L$libdir" + add_dir="" the toolchain should already know which lib paths to search.
any
This bug is idling. Is this bug not assigned correctly? (In reply to comment #6) > Created attachment 184947 [details, diff] > Improved libtool fix What's the status on getting this patch into the tree?
*** Bug 446182 has been marked as a duplicate of this bug. ***
*** Bug 555260 has been marked as a duplicate of this bug. ***
*** Bug 555332 has been marked as a duplicate of this bug. ***
Should be fixed in libtool-2.5.4
