When I attempt to cross-compile x11-base/xorg-server with crossdev, i.e. `armv7a-hardroot-linux-gnueabi xorg-server`, the process fails on the x11-libs/libxcb and x11-libs/libX11 dependencies. Reproducible: Always Steps to Reproduce: 1.Install crossdev for armv7a-hardfloat-linux-gnueabi (this involves creating or using an existing overlay: `crossdev -t armv7a-hardfloat-linux-gnueabi -oO /path/to/the/overlay` 2.emerge --onlydeps -1 libxcb libX11 3.armv7a-hardfloat-linux-gnueabi-emerge libxcb libX11 Actual Results: The install phase fails with ``` libtool: install: (cd /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/x11-libs/libxcb-1.11.1/work/libxcb-1.11.1-.default/src; /bin/sh "/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/x11-libs/libxcb-1.11.1/work/libxcb-1.11.1-.default/libtool" --tag CC --mode=relink armv7a-hardfloat-linux-gnueabi-gcc -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -O2 -pipe -fomit-frame-pointer -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mtls-dialect=gnu2 -version-info 0:0:0 -no-undefined -o libxcb-composite.la -rpath /usr/lib composite.lo libxcb.la -inst-prefix-dir /usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/x11-libs/libxcb-1.11.1/image/) ``` ``` libtool: relink: armv7a-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/composite.o -L/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/x11-libs/libxcb-1.11.1/image//usr/lib -L/usr/lib -lxcb -lXau -lXdmcp -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mtls-dialect=gnu2 -Wl,-soname -Wl,libxcb-composite.so.0 -o .libs/libxcb-composite.so.0.0.0 ``` ``` /usr/lib/libXau.so: file not recognized: File format not recognized collect2: error: ld returned 1 exit status ``` Expected Results: The following is the problem: ``` libtool: relink: armv7a-hardfloat-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/composite.o -L/usr/armv7a-hardfloat-linux-gnueabi/tmp/portage/x11-libs/libxcb-1.11.1/image//usr/lib -L/usr/lib -lxcb -lXau -lXdmcp -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mtls-dialect=gnu2 -Wl,-soname -Wl,libxcb-composite.so.0 -o .libs/libxcb-composite.so.0.0.0 ``` It's trying to link against the host system :(. The `-L/usr/lib` should be `-L/usr/armv7a-hardfloat-linux-gnueabi/usr/lib`. The `ELT-patches/cross/link-ROOT` patch aligns with libtool 2.4.2, but ltmain.sh was changed for libtool 2.4.4 and the patch no longer works: ``` wget http://mirrors.ocf.berkeley.edu/gnu/libtool/libtool-2.4.2.tar.xz tar xf libtool-2.4.2.tar.xz wget http://mirrors.ocf.berkeley.edu/gnu/libtool/libtool-2.4.4.tar.xz tar xf libtool-2.4.4.tar.xz head -n 6924 libtool-2.4.2/libltdl/config/ltmain.sh | tail -n 24 > ltmain.sh-2.4.2 head -n 8339 libtool-2.4.4/build-aux/ltmain.sh | tail -n 24 > ltmain.sh-2.4.4 git diff ltmain.sh-2.4.2 ltmain.sh-2.4.4 ``` I've used the following successfully for x11-libs/libxcb and x11-libs/libX11: ``` --- libltdl/config/ltmain.sh 2016-01-01 00:00:00.000000000 +0000 +++ libltdl/config/ltmain.sh.new 2016-01-01 00:00:00.000000000 +0000 @@ -5768,7 +5768,7 @@ test no = "$hardcode_direct_absolute"; then add=$libdir/$linklib elif test yes = "$hardcode_minus_L"; then - add_dir=-L$libdir + add_dir=-L$ROOT/$libdir add=-l$name elif test yes = "$hardcode_shlibpath_var"; then case :$finalize_shlibpath: in @@ -5785,7 +5785,7 @@ fi else # We cannot seem to hardcode it, guess we'll fake it. - add_dir=-L$libdir + add_dir=-L$ROOT/$libdir # Try looking first in the location we're being installed to. if test -n "$inst_prefix_dir"; then case $libdir in ``` This is just a hacked version of the old patch that * updates `test "$asdf" = k` to `test k = "$asdf"` and * removes the quotes around variable assignments.
Created attachment 423008 [details, diff] Updated patch for libtool 2.4.4 and later
I've confirmed that the patch applies successfully to 2.4.4, 2.4.5, and 2.4.6. Under 2.4.6, xorg-server cross emerges (after some dependency wrangling) without linker errors. The verdict is still out on runtime errors, though.
(In reply to popham from comment #2) > I've confirmed that the patch applies successfully to 2.4.4, 2.4.5, and > 2.4.6. Under 2.4.6, xorg-server cross emerges (after some dependency > wrangling) without linker errors. The verdict is still out on runtime > errors, though. I still think the real fix should be: - add_dir=-L$libdir +add_dir=-L$lt_sysroot$libdir
(In reply to Joakim Tjernlund from comment #3) > (In reply to popham from comment #2) > > I've confirmed that the patch applies successfully to 2.4.4, 2.4.5, and > > 2.4.6. Under 2.4.6, xorg-server cross emerges (after some dependency > > wrangling) without linker errors. The verdict is still out on runtime > > errors, though. > > I still think the real fix should be: > - add_dir=-L$libdir > +add_dir=-L$lt_sysroot$libdir Agreed. I'm new to Gentoo, and I've been ignoring the Prefix setup.... The $lt_sysroot is already plumbed into the eclasses to carry around additional complexity, e.g. Prefix, that my ${ROOT} substitution misses. On the dev mailing list, I stumbled across some speculation on EAPI 7 regarding crossdev: https://archives.gentoo.org/gentoo-dev/message/859ba797276a11ac2c0cd0a9d1cb2e87. I guess this fix could be in tension with that work, but the `$lt_sysroot` seems like a no-brainer to me. Updating.
Created attachment 423412 [details, diff] Updated patch for libtool 2.4.4 and later--lt_sysroot substitution
Created attachment 423414 [details, diff] Updated patch for libtool 2.4.2--lt_sysroot substitution Intended to replace cross/link-ROOT (use lt_sysroot instead of ROOT)
(In reply to popham from comment #5) > Created attachment 423412 [details, diff] [details, diff] > Updated patch for libtool 2.4.4 and later--lt_sysroot substitution I don't think you should have / in there, it just be: add_dir=-L$lt_sysroot$libdir
Created attachment 423958 [details, diff] Automagic --with-sysroot Add `--with-sysroot=${EROOT}` for all `configure` scripts that support the flag.
Created attachment 423960 [details, diff] For elibtoolize calls, base libraries at sysroot, and remove sysroot from rpaths
Created attachment 423962 [details, diff] For Libtool's locally installed ltmain.sh, base libraries at sysroot, and remove sysroot from rpaths. (Apply in sys-devel/libtool ebuild) sys-devel/libtool patch for the system's local `ltmain.sh`. When I clone the ebuild for local modifications, applying this patch last breaks stuff, so I've been applying it second to last. (There's some `touch` logic in place to avoid the breakage, but it still breaks for some reason. I tried `emake -j1`, but that didn't solve the problem.)
I've finally got a set of fixes that seem to work nicely. When building cairo, I had a problem with a broken rpath; the latest patches to ltmain.sh fix the rpath breakage.
Created attachment 424190 [details, diff] For elibtoolize calls, base libraries at sysroot, and remove sysroot from rpaths Ungoof some whitespace
Hi, How are you applying these patches? Are they all for libtool?
(In reply to Alex Barker from comment #13) > Hi, > > How are you applying these patches? Are they all for libtool? No, comment #10 are for libtool itself and fixes original bug. Comment #12 is for libtools eclasses in portage(/usr/portage/eclass), these are for patching already generated lt_main.sh in ebuilds which are generated with a older/buggy libtool The one in comment #10 will be enough if you intend to rerun libtoolize in your SW.
Ping? Sure would be nice to get this into the tree
*** Bug 582490 has been marked as a duplicate of this bug. ***
i've updated the patches for the obvious cases: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=14aeaa71fdbc23b8004b1c2ba9c4daf325b1ae96 i didn't use the patches posted though as they weren't entirely correct/robust all by themselves, and i don't quite grok the last hunk (yet)
(In reply to SpanKY from comment #17) > i've updated the patches for the obvious cases: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=14aeaa71fdbc23b8004b1c2ba9c4daf325b1ae96 Should you not update sys-devel/libtool too? Cross building an app outside ebuild(directly from src) will not get the path correct and might fail. > > i didn't use the patches posted though as they weren't entirely > correct/robust all by themselves, and i don't quite grok the last hunk (yet)
(In reply to Joakim Tjernlund from comment #18) ELT-patches are for hotfixes/not-quite-great hacks. patching libtool itself has a much higher bar. if you think a change should be in there, it needs to be posted/discussed upstream and have a high confidence of being correct and being inline with the direction the project is going. when we screw up libtool, it doesn't impact just us. devs creating packages and posting them for distribution include that bad code too and it can stick around for quite a long time.
(In reply to SpanKY from comment #19) > (In reply to Joakim Tjernlund from comment #18) > > ELT-patches are for hotfixes/not-quite-great hacks. patching libtool itself > has a much higher bar. if you think a change should be in there, it needs > to be posted/discussed upstream and have a high confidence of being correct > and being inline with the direction the project is going. Discussion with uptream libtool has been tried several times but there but there is no interest/knowledge in cross stuff. > > when we screw up libtool, it doesn't impact just us. devs creating packages > and posting them for distribution include that bad code too and it can stick > around for quite a long time. Right, but add_dir=-L$lt_sysroot$libdir is not new, it is used by others(like OE) for a long time, it only affects sysroot builds and you don't have to send it upstream right away. Another option would be to look into slibtool and possibly use that for cross building, I don't know if slibtool will do sysroot any better but it looks like it is actively developed. https://github.com/midipix-project/slibtool
(In reply to Joakim Tjernlund from comment #20) i don't think trying to replace libtool is a realistic option if you have a patch that you want to add to libtool itself, please file a sep bug to track
*** Bug 573346 has been marked as a duplicate of this bug. ***
Stumbled into this problem, when I tried to compile dev-scheme/guile /var/tmp/portage/dev-scheme/guile-2.0.12-r1/work/guile-2.0.12/config.log: configure:46441: /usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/gcc-bin/5.4.0/armv7a-hardfloat-linux-gnueabi-gcc -o conftest -Ofast -march=armv7- a -mtune=cortex-a9 -mfpu=neon-fp16 -mfloat-abi=hard -pipe -fomit-frame-pointer -Wl,-O1 -Wl,--as-needed conftest.c /usr/lib/libltdl.so /usr/lib/libdl.so >&5 /usr/lib/libltdl.so: file not recognized: File format not recognized collect2: error: ld returned 1 exit status configure:46441: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Guile" | #define PACKAGE_TARNAME "guile" | #define PACKAGE_VERSION "2.0.12" | #define PACKAGE_STRING "GNU Guile 2.0.12" | #define PACKAGE_BUGREPORT "bug-guile@gnu.org" | #define PACKAGE_URL "http://www.gnu.org/software/guile/"
popham, by chanche I just looked at this bug again and I saw this old hunk: + local sysrooted_libdir + sysrooted_libdir=$libdir + func_stripname "$lt_sysroot" '' "$libdir" + libdir=$func_stripname_result eval flag=\"$hardcode_libdir_flag_spec\" + libdir=sysrooted_libdir func_append dep_rpath " $flag" What is that about? It is not included in current Gentoo patches
(In reply to SpanKY from comment #19) > (In reply to Joakim Tjernlund from comment #18) > > ELT-patches are for hotfixes/not-quite-great hacks. patching libtool itself > has a much higher bar. if you think a change should be in there, it needs > to be posted/discussed upstream and have a high confidence of being correct > and being inline with the direction the project is going. > > when we screw up libtool, it doesn't impact just us. devs creating packages > and posting them for distribution include that bad code too and it can stick > around for quite a long time. Now that we also have SYSROOT in portage I think it should be safe to patch hosts libtool with $sysroot. It would be nice if using libtool outside portage did the right thing
