The .la files use paths assuming ROOT=/, which breaks builds inside other paths, such as cross-compile targets.
no .la file should use ROOT. not a bug in DirectFB.
Whatever the bug is, it's still a bug. Compiles fail because it looks for DirectFB in /usr/lib (per the .la file) rather than /usr/armv7a-softfloat-linux-gnueabi/usr/lib
need complete build.log of an failing package as well as emerge --info. reopen once done.
Created attachment 384904 [details] media-libs/libsdl-1.2.15-r4 build.log (In reply to Samuli Suominen from comment #3) > need complete build.log of an failing package as well as emerge --info. > reopen once done. Hard to find libraries in the portage tree that depend on DirectFB, but I was able to reproduce it with: [ebuild N ] media-libs/libsdl-1.2.15-r4 to /usr/armv7a-softfloat-linux-gnueabi/ USE="directfb video -X -aalib -alsa -custom-cflags -dga -fbcon (-ggi) -joystick -libcaca -nas -opengl -oss (-ps3) -pulseaudio -sound -static-libs (-svga) -tslib -xinerama -xv" 0 kB
Created attachment 384906 [details] emerge --info
it's not a bug in any specific package that uses libtool. it's a problem that's always been there, but we've largely ignored because we've instead been dropping .la files for non-static/plugin libs. once the .la files aren't there, the issue no longer shows up. it's also why we have cross-fix-root -- you can run it manually if you want to munge your sysroot's .la files. i have no plan to address this in general since eliding the libtool linker files makes the issue "go away" for the majority of people.
Any particular reason DirectFB installs the .la files? Most packages don't seem to anymore.
(In reply to SpanKY from comment #6) > it's not a bug in any specific package that uses libtool. it's a problem > that's always been there, but we've largely ignored because we've instead > been dropping .la files for non-static/plugin libs. once the .la files > aren't there, the issue no longer shows up. > > it's also why we have cross-fix-root -- you can run it manually if you want > to munge your sysroot's .la files. > > i have no plan to address this in general since eliding the libtool linker > files makes the issue "go away" for the majority of people. Since libtool 2.4.x there is a --with-sysroot= option which presents itself in configure. Passing --with-sysroot=yes makes libtool use if test "$GCC" = yes; then lt_sysroot=`$CC --print-sysroot 2>/dev/null` fi which works fine for .la files. Could we consider patching libtool to default to --with-sysroot=yes ?
*** Bug 546774 has been marked as a duplicate of this bug. ***
CC-ing gnome here since this apparently causes dev-libs/glib crosscompile to fail even when .la files are not installed (bug #546774).
Is it possible that glib comes with its own libtool? I tried to edit the master script (/usr/bin/libtool) and start compiling glib again, my changes weren't reflected in glib working directory so I had to patch libtool directly from there. (See https://bugs.gentoo.org/show_bug.cgi?id=546774#c17)
(In reply to Vince C. from comment #12) > Is it possible that glib comes with its own libtool? I tried to edit the > master script (/usr/bin/libtool) and start compiling glib again, my changes > weren't reflected in glib working directory so I had to patch libtool > directly from there. (See https://bugs.gentoo.org/show_bug.cgi?id=546774#c17) Most likely. To make glib ebuild use your hosts libtool you will have to patch glib ebuild to use eautoreconf/elibtoolize. Hopefully uptream glib will regenerate their shipped libtool in their next release, to make sure, drop upstream a note.
(In reply to Joakim Tjernlund from comment #13) > (In reply to Vince C. from comment #12) > > Is it possible that glib comes with its own libtool? I tried to edit the > > master script (/usr/bin/libtool) and start compiling glib again, my changes > > weren't reflected in glib working directory so I had to patch libtool > > directly from there. (See https://bugs.gentoo.org/show_bug.cgi?id=546774#c17) > > Most likely. To make glib ebuild use your hosts libtool you > will have to patch glib ebuild to use eautoreconf/elibtoolize. > > Hopefully uptream glib will regenerate their shipped libtool in > their next release, to make sure, drop upstream a note. Once you have a new enough libtool i glib you can pass EXTRA_ECONF="--with-sysroot=yes" when emerging glib
I'm interested in patches to test since I'm hitting the same issue. glib-2.40.2 (current arm stable) is doing eautoreconf (in the ebuild) and then elibtoolize (from the eclass) so running libtool from the ebuild workdir, it appears to be version 2.4.6 which is supposed to work well with sysroot however it still fails.
(In reply to Gilles Dartiguelongue from comment #15) > I'm interested in patches to test since I'm hitting the same issue. > > glib-2.40.2 (current arm stable) is doing eautoreconf (in the ebuild) and > then elibtoolize (from the eclass) so running libtool from the ebuild > workdir, it appears to be version 2.4.6 which is supposed to work well with > sysroot however it still fails. Did you pass EXTRA_ECONF="--with-sysroot=yes" when emerging glib? Could you see --with-sysroot=yes in glib build logs?
I did try the following: EXTRA_ECONF="--with-sysroot=yes" armv7a-hardfloat-linux-gnueabi-emerge -a1 glib Result is still the same: libtool: warning: relinking 'libgmodule-2.0.la' libtool: install: (cd /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2-.arm/gmodule; /bin/sh "/usr/armv7a-hardfloat-linux-gnueabi/tmp/po rtage/dev-libs/glib-2.42.2/work/glib-2.42.2-.arm/libtool" --tag CC --mode=relink armv7a-hardfloat-linux-gnueabi-gcc -fvisibility=hidden -O2 -pipe -fomit-frame-pointer -Wl,- Bsymbolic-functions -Wl,--export-dynamic -version-info 4200:2:4200 -export-dynamic -Wl,-O1 -Wl,--as-needed -o libgmodule-2.0.la -rpath /usr/lib libgmodule_2_0_la-gmodule.lo -ldl ../glib/libglib-2.0.la -inst-prefix-dir /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.42.2/image/) libtool: relink: armv7a-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/libgmodule_2_0_la-gmodule.o -ldl -L/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs /glib-2.42.2/image//usr/lib -L/usr/lib -lglib-2.0 -lpthread -O2 -Wl,-Bsymbolic-functions -Wl,--export-dynamic -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,libgmodule-2.0.so.0 -o .libs/libgmodule-2.0.so.0.4200.2 /usr/lib/libdl.so: file not recognized: File format not recognized collect2: error: ld returned 1 exit status So no, (unless I missed something) passing EXTRA_ECONF="--with-sysroot=yes" does not help. I checked libtool version in glib 2.42 and it's version 2.4.6 as exposed earlier.
If that helps: /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2-.arm/libtool @ 38 # ### BEGIN LIBTOOL CONFIG # Which release of libtool.m4 was used? macro_version=2.4.6 macro_revision=2.4.6 /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2-.arm/libtool @ 194 # The root where to search for dependent libraries,and where our libraries should be installed. lt_sysroot=/usr/armv7a-hardfloat-linux-gnueabi /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/dev-libs/glib-2.42.2/work/glib-2.42.2-.arm/libtool --version libtool (GNU libtool) 2.4.6 Written by Gordon Matzigkeit, 1996 [...]
Created attachment 411364 [details, diff] Changes to glib to account for custom libtool patching
Created attachment 411366 [details, diff] Quick'n'dirty fix for crossdev libtool, tested with built-in glib sources I confirm this patch duly works for glib at least. I'll try it, again, against more ebuilds to come and report here. Any other attempt to use known tricks have failed. This is the only one fix to my knowledge that works.
Also works with media-libs/alsa-lib-1.0.29, which didn't install either.
(In reply to Vince C. from comment #21) > Also works with media-libs/alsa-lib-1.0.29, which didn't install either. hmm, are you installing into some other dir than your sysroot? For sysroot to work, you need to have your deps in sysroot
(In reply to Joakim Tjernlund from comment #22) > (In reply to Vince C. from comment #21) > > Also works with media-libs/alsa-lib-1.0.29, which didn't install either. > > hmm, are you installing into some other dir than your sysroot? > > For sysroot to work, you need to have your deps in sysroot Since I'm using crossdev and bug #546774 (which I reported) was marked as a duplicate of this bug, I have to say "yes, I do".
(In reply to Vince C. from comment #23) > (In reply to Joakim Tjernlund from comment #22) > > (In reply to Vince C. from comment #21) > > > Also works with media-libs/alsa-lib-1.0.29, which didn't install either. > > > > hmm, are you installing into some other dir than your sysroot? > > > > For sysroot to work, you need to have your deps in sysroot > > Since I'm using crossdev and bug #546774 (which I reported) was marked as a > duplicate of this bug, I have to say "yes, I do". Have you tried building PAM as descibed here? https://bugs.gentoo.org/show_bug.cgi?id=511468 --sysroot seems to work here. It could be a bug in newest libtool, I played some with this but then with libtool 2.4.2
(In reply to Joakim Tjernlund from comment #24) > (In reply to Vince C. from comment #23) > > (In reply to Joakim Tjernlund from comment #22) > > > hmm, are you installing into some other dir than your sysroot? > > [...] > > Since I'm using crossdev and bug #546774 (which I reported) was marked as a > > duplicate of this bug, I have to say "yes, I do". > > Have you tried building PAM as descibed here? > https://bugs.gentoo.org/show_bug.cgi?id=511468 > --sysroot seems to work here. > > It could be a bug in newest libtool, I played some with this but > then with libtool 2.4.2 I've just emerged pam-1.2.1 again as described. No error. I'm not sure I understand what you want to know however. I haven't had troubles with PAM on the Gentoo host system on which I am cross-compiling. I am not using PAM on the ARM platform on the other hand. The only packages that failed cross-compilation, which was easily solved with the above method though, are these ones: media-libs/libvorbis/libvorbis-1.3.4.ebuild media-libs/flac/flac-1.3.1-r1.ebuild media-libs/mesa/mesa-10.6.5.ebuild media-libs/alsa-lib/alsa-lib-1.0.29.ebuild sys-devel/gettext/gettext-0.19.4.ebuild x11-libs/libxcb/libxcb-1.11-r1.ebuild x11-libs/cairo/cairo-1.14.2.ebuild x11-libs/libX11/libX11-1.6.2.ebuild dev-libs/glib/glib-2.42.2.ebuild dev-libs/libxslt/libxslt-1.1.28-r4.ebuild These packages come with an embedded version of libtool. They're not the only ones of course but the only ones I've had to fix. Do you want me to run EXTRA_ECONF="--with-sysroot=yes" emerge <package> or EXTRA_ECONF="--with-sysroot=yes" armv7a-hardfloat-linux-gnueabi-emerge <package> or both? What I do not understand is `what is EXTRA_ECONF="--with-sysroot=yes" emerge <package> supposed to do if only cross-compiling fails?'
Damn'it, be rigorous, Vince! > The only packages that failed cross-compilation, which was easily solved with the above method [...] should read: The only packages that failed cross-compilation, which was easily solved with *my* method [...]
(In reply to Vince C. from comment #25) > (In reply to Joakim Tjernlund from comment #24) > > (In reply to Vince C. from comment #23) > > > (In reply to Joakim Tjernlund from comment #22) > > > > hmm, are you installing into some other dir than your sysroot? > > > [...] > > > Since I'm using crossdev and bug #546774 (which I reported) was marked as a > > > duplicate of this bug, I have to say "yes, I do". > > > > Have you tried building PAM as descibed here? > > https://bugs.gentoo.org/show_bug.cgi?id=511468 > > --sysroot seems to work here. > > > > It could be a bug in newest libtool, I played some with this but > > then with libtool 2.4.2 > > I've just emerged pam-1.2.1 again as described. No error. > > I'm not sure I understand what you want to know however. I haven't had > troubles with PAM on the Gentoo host system on which I am cross-compiling. I > am not using PAM on the ARM platform on the other hand. > > The only packages that failed cross-compilation, which was easily solved > with the above method though, are these ones: > > media-libs/libvorbis/libvorbis-1.3.4.ebuild > media-libs/flac/flac-1.3.1-r1.ebuild > media-libs/mesa/mesa-10.6.5.ebuild > media-libs/alsa-lib/alsa-lib-1.0.29.ebuild > sys-devel/gettext/gettext-0.19.4.ebuild > x11-libs/libxcb/libxcb-1.11-r1.ebuild > x11-libs/cairo/cairo-1.14.2.ebuild > x11-libs/libX11/libX11-1.6.2.ebuild > dev-libs/glib/glib-2.42.2.ebuild > dev-libs/libxslt/libxslt-1.1.28-r4.ebuild > > These packages come with an embedded version of libtool. They're not the > only ones of course but the only ones I've had to fix. Guessing here now, but these pkg's tries to link against its OWN .la files? Here --sysroot won't help and I cannot say whether it is libtools fault or the packages build system/use of libtool. Best is probably ask the libtool mailing list. The PAM case is about linking to other pgks .la files already installed in sysroot. > > > Do you want me to run > > EXTRA_ECONF="--with-sysroot=yes" emerge <package> no > > or > > EXTRA_ECONF="--with-sysroot=yes" armv7a-hardfloat-linux-gnueabi-emerge > <package> yes, this is the one I mean. Sorry about the confusion. > > or both? What I do not understand is `what is > EXTRA_ECONF="--with-sysroot=yes" emerge <package> supposed to do if only > cross-compiling fails?' Nothing useful
Okay. So I've tried the following: EXTRA_ECONF="--with-sysroot=yes" armv7a-hardfloat-linux-gnueabi-emerge <package> with <package> being, respectively - flac-1.3.1-r1 - libvorbis-1.3.4 - alsa-lib-1.0.29 None of these packages did install, due to the infamous "file not recognized: File format not recognized" error. I was bored^Wlazy and didn't try any further package from my list. So far only what I mentioned in comment #19 does fix the issue. Of all the packages that fail only gettext had to be processed somewhat differently because it has three libtool instances. But all libtool instances are patched using the same method in comment #19, i.e. append the four lines (bottom of) the ebuild `multilib_src_configure()'.
(In reply to Vince C. from comment #28) > So far only what I mentioned in comment #19 does fix the issue. Of all the > packages that fail only gettext had to be processed somewhat differently > because it has three libtool instances. But all libtool instances are > patched using the same method in comment #19, i.e. append the four lines > (bottom of) the ebuild `multilib_src_configure()'. Must be not my day today... > But all libtool instances are patched using the same method in comment #19 [...] should read But all libtool instances are patched using the same method in comment #20 [...]
I've also run (this time against the *target* instead of the *compiling* host) EXTRA_ECONF="--with-sysroot=yes" armv7a-hardfloat-linux-gnueabi-emerge pam and it installs properly, no "unrecognised format" error. I've then tried to run armv7a-hardfloat-linux-gnueabi-emerge pam and then I get that error message. So case closed as far as PAM is concerned. Just that I don't need it on my target platform but that's good to know.
(In reply to Vince C. from comment #30) > I've also run (this time against the *target* instead of the *compiling* > host) > > EXTRA_ECONF="--with-sysroot=yes" armv7a-hardfloat-linux-gnueabi-emerge pam > > and it installs properly, no "unrecognised format" error. I've then tried to > run > > armv7a-hardfloat-linux-gnueabi-emerge pam > > and then I get that error message. So case closed as far as PAM is > concerned. Just that I don't need it on my target platform but that's good > to know. right, having just completed a 5 hour drive on which I had plenty of time I think I know what the problem is. I think libtool adds the following search dirs: $sysroot / $DESTDIR$prefix This would explain why PAM works and glib doesn't There are two errors here: 1) libtool still hardcode / as sysroot in some places. I should only use $sysroot 2) search order is wrong, it should be $DESTDIR$prefix $sysroot first search your own newly built libs before picking up an older version in $sysroot to confirm you can print add_dir and see for your self.
I realized I overlooked one of your comments... (In reply to Joakim Tjernlund from comment #27) > (In reply to Vince C. from comment #25) ... > > The only packages that failed cross-compilation, which was easily solved > > with the above method though, are these ones: > > > > media-libs/libvorbis/libvorbis-1.3.4.ebuild > > media-libs/flac/flac-1.3.1-r1.ebuild > > media-libs/mesa/mesa-10.6.5.ebuild > > media-libs/alsa-lib/alsa-lib-1.0.29.ebuild > > sys-devel/gettext/gettext-0.19.4.ebuild > > x11-libs/libxcb/libxcb-1.11-r1.ebuild > > x11-libs/cairo/cairo-1.14.2.ebuild > > x11-libs/libX11/libX11-1.6.2.ebuild > > dev-libs/glib/glib-2.42.2.ebuild > > dev-libs/libxslt/libxslt-1.1.28-r4.ebuild > > > > These packages come with an embedded version of libtool. They're not the > > only ones of course but the only ones I've had to fix. > > Guessing here now, but these pkg's tries to link against its OWN .la files? > Here --sysroot won't help and I cannot say whether it is libtools fault > or the packages build system/use of libtool. Yes, these are trying to link against their own .la files. Removing them is even worse as the link command expects them. Moreover libtool is generated from a bunch of things I was overwhelmed trying to understand how they work. > Best is probably ask the libtool mailing list. Done as of last Mondy. Still waiting for a response.
(In reply to Vince C. from comment #32) > I realized I overlooked one of your comments... > > (In reply to Joakim Tjernlund from comment #27) > > (In reply to Vince C. from comment #25) > ... > > > The only packages that failed cross-compilation, which was easily solved > > > with the above method though, are these ones: > > > > > > media-libs/libvorbis/libvorbis-1.3.4.ebuild > > > media-libs/flac/flac-1.3.1-r1.ebuild > > > media-libs/mesa/mesa-10.6.5.ebuild > > > media-libs/alsa-lib/alsa-lib-1.0.29.ebuild > > > sys-devel/gettext/gettext-0.19.4.ebuild > > > x11-libs/libxcb/libxcb-1.11-r1.ebuild > > > x11-libs/cairo/cairo-1.14.2.ebuild > > > x11-libs/libX11/libX11-1.6.2.ebuild > > > dev-libs/glib/glib-2.42.2.ebuild > > > dev-libs/libxslt/libxslt-1.1.28-r4.ebuild > > > > > > These packages come with an embedded version of libtool. They're not the > > > only ones of course but the only ones I've had to fix. > > > > Guessing here now, but these pkg's tries to link against its OWN .la files? > > Here --sysroot won't help and I cannot say whether it is libtools fault > > or the packages build system/use of libtool. > > Yes, these are trying to link against their own .la files. Removing them is > even worse as the link command expects them. Moreover libtool is generated > from a bunch of things I was overwhelmed trying to understand how they work. > > > > Best is probably ask the libtool mailing list. > > Done as of last Mondy. Still waiting for a response. I looked a bit at your libtool patch for similar cases and if there was any differences, there is: add_dir=-L$absdir # Try looking first in the location we're being installed to. if test -n "$inst_prefix_dir"; then case $libdir in [\\/]*) func_append add_dir " -L$inst_prefix_dir$libdir" ;; esac and then 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 [\\/]*) func_append add_dir " -L$inst_prefix_dir$libdir" ;; esac Notice the "add_dir=-L$absdir" vs. "add_dir=-L$libdir" difference? What if you change the failing one to what the other case uses?
Interesting old redhat bug about similar problem: https://bugzilla.redhat.com/show_bug.cgi?id=58664 googling for libtool relink exposes lots of similar problem with /usr/lib being hardcoded.
(In reply to Joakim Tjernlund from comment #33) ... snipped ... > I looked a bit at your libtool patch for similar cases and if there was any > differences, there is: > add_dir=-L$absdir > # Try looking first in the location we're being installed to. > if test -n "$inst_prefix_dir"; then > case $libdir in > [\\/]*) > func_append add_dir " -L$inst_prefix_dir$libdir" > ;; > esac > and then > 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 > [\\/]*) > func_append add_dir " -L$inst_prefix_dir$libdir" > ;; > esac > > Notice the "add_dir=-L$absdir" vs. "add_dir=-L$libdir" difference? > What if you change the failing one to what the other case uses? Bingo! I used alsa-lib as a test subject. It installed without error when I replaced add_dir=-L$libdir with add_dir=-L$absdir. I then restarted the install after reverting the change and it failed to install. You've nailed it down! Kudos!
(In reply to Vince C. from comment #35) > (In reply to Joakim Tjernlund from comment #33) > ... snipped ... > > I looked a bit at your libtool patch for similar cases and if there was any > > differences, there is: > > add_dir=-L$absdir > > # Try looking first in the location we're being installed to. > > if test -n "$inst_prefix_dir"; then > > case $libdir in > > [\\/]*) > > func_append add_dir " -L$inst_prefix_dir$libdir" > > ;; > > esac > > and then > > 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 > > [\\/]*) > > func_append add_dir " -L$inst_prefix_dir$libdir" > > ;; > > esac > > > > Notice the "add_dir=-L$absdir" vs. "add_dir=-L$libdir" difference? > > What if you change the failing one to what the other case uses? > > Bingo! I used alsa-lib as a test subject. It installed without error when I > replaced add_dir=-L$libdir with add_dir=-L$absdir. I then restarted the > install after reverting the change and it failed to install. You've nailed > it down! Kudos! :), nice that it helped. I am far from sure this is the rigth fix though. How does the failing link cmd change when this fix is applied?
(In reply to Joakim Tjernlund from comment #36) > (In reply to Vince C. from comment #35) > > (In reply to Joakim Tjernlund from comment #33) > > ... snipped ... > > > I looked a bit at your libtool patch for similar cases and if there was any > > > differences, there is: > > > add_dir=-L$absdir > > > # Try looking first in the location we're being installed to. > > > if test -n "$inst_prefix_dir"; then > > > case $libdir in > > > [\\/]*) > > > func_append add_dir " -L$inst_prefix_dir$libdir" > > > ;; > > > esac > > > and then > > > 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 > > > [\\/]*) > > > func_append add_dir " -L$inst_prefix_dir$libdir" > > > ;; > > > esac > > > > > > Notice the "add_dir=-L$absdir" vs. "add_dir=-L$libdir" difference? > > > What if you change the failing one to what the other case uses? > > > > Bingo! I used alsa-lib as a test subject. It installed without error when I > > replaced add_dir=-L$libdir with add_dir=-L$absdir. I then restarted the > > install after reverting the change and it failed to install. You've nailed > > it down! Kudos! > > :), nice that it helped. > > I am far from sure this is the rigth fix though. > How does the failing link cmd change when this fix is applied? FYI, I am hoping absdir translates to $sysroot/usr/lib but if it does not maybe it should be changed to: add_dir=-L$lt_systoot$libdir
> it should be changed to: > add_dir=-L$lt_systoot$libdir add_dir=-L$lt_sysroot$libdir
(In reply to Joakim Tjernlund from comment #36) > (In reply to Vince C. from comment #35) > > (In reply to Joakim Tjernlund from comment #33) > > ... snipped ... > > > I looked a bit at your libtool patch for similar cases and if there was any > > > differences, there is: > > > add_dir=-L$absdir > > > # Try looking first in the location we're being installed to. > > > if test -n "$inst_prefix_dir"; then > > > case $libdir in > > > [\\/]*) > > > func_append add_dir " -L$inst_prefix_dir$libdir" > > > ;; > > > esac > > > and then > > > 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 > > > [\\/]*) > > > func_append add_dir " -L$inst_prefix_dir$libdir" > > > ;; > > > esac > > > > > > Notice the "add_dir=-L$absdir" vs. "add_dir=-L$libdir" difference? > > > What if you change the failing one to what the other case uses? > > > > Bingo! I used alsa-lib as a test subject. It installed without error when I > > replaced add_dir=-L$libdir with add_dir=-L$absdir. I then restarted the > > install after reverting the change and it failed to install. You've nailed > > it down! Kudos! > > :), nice that it helped. > > I am far from sure this is the rigth fix though. > How does the failing link cmd change when this fix is applied? BTW, if this all works out you could look at adding a libtool patch to /usr/portage/eclass/ELT-patches/fix-relink and have libtool eclass autopatch ltmain.sh
Created attachment 411956 [details] vanilla media-libs/alsa-lib-1.0.29 build log (unpatched libtool) (In reply to Joakim Tjernlund from comment #36) > (In reply to Vince C. from comment #35) [...] > > Bingo! I used alsa-lib as a test subject. It installed without error when I > > replaced add_dir=-L$libdir with add_dir=-L$absdir. I then restarted the > > install after reverting the change and it failed to install. You've nailed > > it down! Kudos! > > :), nice that it helped. > > I am far from sure this is the rigth fix though. > How does the failing link cmd change when this fix is applied? Here's alsa-lib-1.0.29 log when building from portage, unpatched.
Created attachment 411958 [details] media-libs/alsa-lib-1.0.29 build log (patched libtool using $absdir) This is alsa-lib-1.0.29 with libtool using $absdir instead of $libdir. (See comment #33.)
(In reply to Joakim Tjernlund from comment #39) > BTW, if this all works out you could look at adding a libtool patch to > /usr/portage/eclass/ELT-patches/fix-relink > and have libtool eclass autopatch ltmain.sh That's exactly the place I was curious to know, where to put patches that apply systematically, instead of patching every failing ebuild. Will do that and report here. Thanks a lot for your insights again.
(In reply to Vince C. from comment #41) > Created attachment 411958 [details] > media-libs/alsa-lib-1.0.29 build log (patched libtool using $absdir) > > This is alsa-lib-1.0.29 with libtool using $absdir instead of $libdir. (See > comment #33.) This appears to be the wrong log, it fails relinking too.
(In reply to Joakim Tjernlund from comment #43) > (In reply to Vince C. from comment #41) > > Created attachment 411958 [details] > > media-libs/alsa-lib-1.0.29 build log (patched libtool using $absdir) > > > > This is alsa-lib-1.0.29 with libtool using $absdir instead of $libdir. (See > > comment #33.) > > This appears to be the wrong log, it fails relinking too. Uh? I've checked and here's how it ends: ... make[2]: Leaving directory '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm' make[1]: Leaving directory '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm' * Removing unnecessary /usr/lib/libasound.la (requested) * Removing unnecessary /usr/lib/alsa-lib/smixer/smixer-ac97.la (module) * Removing unnecessary /usr/lib/alsa-lib/smixer/smixer-sbase.la (module) * Removing unnecessary /usr/lib/alsa-lib/smixer/smixer-hda.la (module) >>> Completed installing alsa-lib-1.0.29 into /portage/tmp/portage/media-libs/alsa-lib-1.0.29/image/ strip: armv7a-hardfloat-linux-gnueabi-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version usr/lib/alsa-lib/smixer/smixer-ac97.so usr/lib/alsa-lib/smixer/smixer-sbase.so usr/lib/libasound.so.2.0.0 usr/lib/alsa-lib/smixer/smixer-hda.so usr/bin/aserver ecompressdir: bzip2 -9 /usr/share/doc Could it be your browser's cache for both log files wore the same name when I attached them.
(In reply to Vince C. from comment #44) > (In reply to Joakim Tjernlund from comment #43) > > (In reply to Vince C. from comment #41) > > > Created attachment 411958 [details] > > > media-libs/alsa-lib-1.0.29 build log (patched libtool using $absdir) > > > > > > This is alsa-lib-1.0.29 with libtool using $absdir instead of $libdir. (See > > > comment #33.) > > > > This appears to be the wrong log, it fails relinking too. > > Uh? > > I've checked and here's how it ends: > > ... > make[2]: Leaving directory > '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm' > make[1]: Leaving directory > '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm' > * Removing unnecessary /usr/lib/libasound.la (requested) > * Removing unnecessary /usr/lib/alsa-lib/smixer/smixer-ac97.la (module) > * Removing unnecessary /usr/lib/alsa-lib/smixer/smixer-sbase.la (module) > * Removing unnecessary /usr/lib/alsa-lib/smixer/smixer-hda.la (module) > >>> Completed installing alsa-lib-1.0.29 into /portage/tmp/portage/media-libs/alsa-lib-1.0.29/image/ > > strip: armv7a-hardfloat-linux-gnueabi-strip --strip-unneeded -R .comment -R > .GCC.command.line -R .note.gnu.gold-version > usr/lib/alsa-lib/smixer/smixer-ac97.so > usr/lib/alsa-lib/smixer/smixer-sbase.so > usr/lib/libasound.so.2.0.0 > usr/lib/alsa-lib/smixer/smixer-hda.so > usr/bin/aserver > ecompressdir: bzip2 -9 /usr/share/doc > > Could it be your browser's cache for both log files wore the same name when > I attached them. Yes, I see that now. However there is still the same relink error but the build continues anyway(how ?). It says: libtool: warning: relinking 'smixer-sbase.la' libtool: install: (cd /portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm/modules/mixer/simple; /bin/sh "/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm/libtool" --tag CC --mode=relink armv7a-hardfloat-linux-gnueabi-gcc -W -Wall -O2 -pipe -fomit-frame-pointer -D_GNU_SOURCE -module -avoid-version -Wl,--no-undefined -Wl,-O1 -Wl,--as-needed -o smixer-sbase.la -rpath /usr/lib/alsa-lib/smixer sbase.lo ../../../src/libasound.la -inst-prefix-dir /portage/tmp/portage/media-libs/alsa-lib-1.0.29/image/) libtool: relink: armv7a-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/sbase.o -L/portage/tmp/portage/media-libs/alsa-lib-1.0.29/image//usr/lib -L/usr/lib -lasound -lm -ldl -lpthread -lrt -O2 -Wl,--no-undefined -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,smixer-sbase.so -o .libs/smixer-sbase.so /usr/lib/libm.so: file not recognized: File format not recognized collect2: error: ld returned 1 exit status libtool: error: error: relink 'smixer-sbase.la' with the above command before installing it Makefile:424: recipe for target 'install-pkglibLTLIBRARIES' failed make[4]: *** [install-pkglibLTLIBRARIES] Error 1 make[4]: Leaving directory '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm/modules/mixer/simple' Makefile:611: recipe for target 'install-am' failed make[3]: *** [install-am] Error 2 make[3]: Leaving directory '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm/modules/mixer/simple' Makefile:363: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm/modules/mixer' Makefile:363: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/portage/tmp/portage/media-libs/alsa-lib-1.0.29/work/alsa-lib-1.0.29-.arm/modules' Makefile:402: recipe for target 'install-recursive' failed make: *** [install-recursive] Error 1
As the absdir stuff appears to fail in some other way I think we are back to adding $lt_sysroot. Either by just changing the same line to add_dir=-L$lt_sysroot$libdir or in this snippet: else if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; then dir=$ladir absdir=$abs_ladir # Remove this search path later func_append notinst_path " $abs_ladir" else dir=$ladir/$objdir absdir=$abs_ladir/$objdir # Remove this search path later func_append notinst_path " $abs_ladir" fi but in this there is no libdir, I don't really understand how manage the different dir, absdir and libdir here. So the simpler add_dir=-L$lt_sysroot$libdir migth be best.
(In reply to Joakim Tjernlund from comment #46) > As the absdir stuff appears to fail in some other way I think we are back to > adding $lt_sysroot. > > Either by just changing the same line to > add_dir=-L$lt_sysroot$libdir > > or in this snippet: > else > if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; > then > dir=$ladir > absdir=$abs_ladir > # Remove this search path later > func_append notinst_path " $abs_ladir" > else > dir=$ladir/$objdir > absdir=$abs_ladir/$objdir > # Remove this search path later > func_append notinst_path " $abs_ladir" > fi > but in this there is no libdir, I don't really understand how manage > the different dir, absdir and libdir here. I don't have any idea. However I did trace libtool in glib and -- IIRC -- I found out the reference to /usr/lib that makes libtool lookup in the host rather than the target system comes from the .la file. I then thought: if the [install] prefix is given (`if test -n "$inst_prefix_dir"; then`), don't add the directory, replace it (`add_dir="-L$inst_prefix_dir$libdir"`). If you closely look at the complete libtool command, there is -L/usr/lib -L/some/other/path ... -L/yet/some/other/path, which gets reordered in a libtool variable as "-L/yet/some/other/path -L/some/other/path -L/usr/lib". I verified, the "/usr/lib" occurrence comes from the package .la file. Every other path is correct and accounts for crossdev environments. Because "/usr/bin" is added first to the path list, I assumed whenever subsequent paths are appended, they must be legit so I just take the last that gets added to the list, discarding the previous ones; this seems to make every failing case work. In a non-crossdev environment this assumption at least worked for a couple of packages that I tested (2-3 actually but I don't remember which ones, possibly glib is amongst them, I'm not sure). What do you think of this approach?
(In reply to Vince C. from comment #47) > ... (`if test -n "$inst_prefix_dir"; then`), don't add the directory, > replace it (`add_dir="-L$inst_prefix_dir$libdir"`). Should read: ... (`if test -n "$inst_prefix_dir"; then`), don't add the directory, overwrite the list with it (`add_dir="-L$inst_prefix_dir$libdir"`).
(In reply to Vince C. from comment #47) > (In reply to Joakim Tjernlund from comment #46) > > As the absdir stuff appears to fail in some other way I think we are back to > > adding $lt_sysroot. > > > > Either by just changing the same line to > > add_dir=-L$lt_sysroot$libdir > > > > or in this snippet: > > else > > if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; > > then > > dir=$ladir > > absdir=$abs_ladir > > # Remove this search path later > > func_append notinst_path " $abs_ladir" > > else > > dir=$ladir/$objdir > > absdir=$abs_ladir/$objdir > > # Remove this search path later > > func_append notinst_path " $abs_ladir" > > fi > > but in this there is no libdir, I don't really understand how manage > > the different dir, absdir and libdir here. > > I don't have any idea. > > However I did trace libtool in glib and -- IIRC -- I found out the reference > to /usr/lib that makes libtool lookup in the host rather than the target > system comes from the .la file. I then thought: if the [install] prefix is > given (`if test -n "$inst_prefix_dir"; then`), don't add the directory, > replace it (`add_dir="-L$inst_prefix_dir$libdir"`). > > If you closely look at the complete libtool command, there is -L/usr/lib > -L/some/other/path ... -L/yet/some/other/path, which gets reordered in a > libtool variable as "-L/yet/some/other/path -L/some/other/path -L/usr/lib". > I verified, the "/usr/lib" occurrence comes from the package .la file. Every > other path is correct and accounts for crossdev environments. > > Because "/usr/bin" is added first to the path list, I assumed whenever > subsequent paths are appended, they must be legit so I just take the last > that gets added to the list, discarding the previous ones; this seems to > make every failing case work. In a non-crossdev environment this assumption > at least worked for a couple of packages that I tested (2-3 actually but I > don't remember which ones, possibly glib is amongst them, I'm not sure). > > What do you think of this approach? I think you must end up with $inst_prefix_dir$libdir $lt_sysroot$libdir or it will break in some cases. As long as the searched lib (like -ldl) is in gcc default seach path you can skip $lt_sysroot$libdir, but there are libs in $sysroot which are in non gcc default search dir. This is not my thinking but from https://bugzilla.redhat.com/show_bug.cgi?id=58664 Therefore try add_dir=-L$lt_sysroot$libdir and verify that .la files and search path to gcc is -L$inst_prefix_dir$libdir -L$lt_sysroot$libdir
Curious, any progress ?
(In reply to Joakim Tjernlund from comment #50) > Curious, any progress ? In any case not on my side. I have put compiling on pause for now, other stuff to manage. Will resume shortly I hope.
Wait... wut? > Bug 521184 - handling of libtool linker scripts and SYSROOT > ... > Component: Games Uh? Shouldn't it be "Development" ?
I think I figured this one out over at https://bugs.gentoo.org/show_bug.cgi?id=572038. The problem is that an automagic patch doesn't get applied for newer libtool (2.4.4 and later).
Thank you for taking the time to share with us such a nice article. https://bit.ly/3wjNQFm
I think this is fixed in libtool 2.5.1
I think all Gentoo significant libtool changes are in 2.5.1 beta, perhaps adding libtool 2.5.1 in Gentoo would be beneficial to find any fallout before the real libtool release?
It won't be keyworded anyway (especially so given what happened with arch and the file thing) but I did look when it came out but hit some test issues and didn't go back to it. Feel free to investigate that.
(In reply to Sam James from comment #57) > It won't be keyworded anyway (especially so given what happened with arch > and the file thing) but I did look when it came out but hit some test issues > and didn't go back to it. Feel free to investigate that. I see you are happy now with 2.5.1 and it is in Gentoo, thanks! Installed it on my home machine to test it a bit. I guess the only missing part left is what to do with SYSROOT in elt-patches. Also, poky has few extra patches that probably makes sense for Gentoo as well: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/libtool/libtool
(In reply to Joakim Tjernlund from comment #49) > (In reply to Vince C. from comment #47) > > (In reply to Joakim Tjernlund from comment #46) > > > As the absdir stuff appears to fail in some other way I think we are back to > > > adding $lt_sysroot. > > > > > > Either by just changing the same line to > > > add_dir=-L$lt_sysroot$libdir > > > > > > or in this snippet: > > > else > > > if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; > > > then > > > dir=$ladir > > > absdir=$abs_ladir > > > # Remove this search path later > > > func_append notinst_path " $abs_ladir" > > > else > > > dir=$ladir/$objdir > > > absdir=$abs_ladir/$objdir > > > # Remove this search path later > > > func_append notinst_path " $abs_ladir" > > > fi > > > but in this there is no libdir, I don't really understand how manage > > > the different dir, absdir and libdir here. > > > > I don't have any idea. > > > > However I did trace libtool in glib and -- IIRC -- I found out the reference > > to /usr/lib that makes libtool lookup in the host rather than the target > > system comes from the .la file. I then thought: if the [install] prefix is > > given (`if test -n "$inst_prefix_dir"; then`), don't add the directory, > > replace it (`add_dir="-L$inst_prefix_dir$libdir"`). > > > > If you closely look at the complete libtool command, there is -L/usr/lib > > -L/some/other/path ... -L/yet/some/other/path, which gets reordered in a > > libtool variable as "-L/yet/some/other/path -L/some/other/path -L/usr/lib". > > I verified, the "/usr/lib" occurrence comes from the package .la file. Every > > other path is correct and accounts for crossdev environments. > > > > Because "/usr/bin" is added first to the path list, I assumed whenever > > subsequent paths are appended, they must be legit so I just take the last > > that gets added to the list, discarding the previous ones; this seems to > > make every failing case work. In a non-crossdev environment this assumption > > at least worked for a couple of packages that I tested (2-3 actually but I > > don't remember which ones, possibly glib is amongst them, I'm not sure). > > > > What do you think of this approach? > > I think you must end up with $inst_prefix_dir$libdir $lt_sysroot$libdir or > it will break in some cases. > As long as the searched lib (like -ldl) is in gcc default seach path you can > skip $lt_sysroot$libdir, but there are libs in $sysroot which are in non gcc > default search dir. This is not my thinking but from > https://bugzilla.redhat.com/show_bug.cgi?id=58664 https://slopeonline.online/ > > Therefore try add_dir=-L$lt_sysroot$libdir and verify that .la files and > search path to gcc is -L$inst_prefix_dir$libdir -L$lt_sysroot$libdir The issue is that an automatic patch is not applied for newer versions of libtool (2.4.4 & later).
