Created attachment 487036 [details] build.log Hello. When cross-emerging binutils-libs it looks for zlib in /usr/lib instead of /usr/CHOST/usr/lib: libtool: relink: arm-unknown-linux-gnueabi-gcc -shared -fPIC -DPIC .libs/dis-buf.o .libs/disassemble.o .libs/dis-init.o .libs/arm-dis.o -L/var/tmp/portage/sys-libs/binutils-libs-2.28-r1/image//usr/lib -L/usr/lib -lbfd -L/var/tmp/portage/sys-libs/binutils-libs-2.28-r1/work/binutils-2.28-.default/bfd/../libiberty/pic -lz -ldl -L/var/tmp/portage/sys-libs/binutils-libs-2.28-r1/work/binutils-2.28-.default/opcodes/../libiberty/pic -liberty -Wl,--hash-style=gnu -Wl,-lc -Wl,--as-needed -Wl,-lm -Wl,--no-as-needed -Wl,-soname -Wl,libopcodes-2.28.so -o .libs/libopcodes-2.28.so /usr/libexec/gcc/arm-unknown-linux-gnueabi/ld: skipping incompatible /usr/lib/libz.so when searching for -lz /usr/lib/libdl.so: file not recognized: File format not recognized collect2: error: ld returned 1 exit status
Created attachment 487038 [details] arm-unknown-linux-gnueabi-emerge --info
Created attachment 487040 [details] emerge --info
Do you already have zlib installed in /usr/${STARGET}?
(In reply to Sergei Trofimovich from comment #3) > Do you already have zlib installed in /usr/${STARGET}? Of course. Other packages like libxml2, libpng, freetype all were built successfully against it too.
Do you have /usr/${CTARGET}/usr/lib/libz.la file installed? (It's usually there when zlib is built with USE=static-libs). I still don't know how .la file are supposed to be used properly in cross-environment. I only know how they break :) https://bugs.gentoo.org/642174#c3 One of the workarounds is to use USE=-static-libs if possible. Another is ${CTARGET}-fix-root mangler to prepend ${SYSROOT} paths to libraries.
I have the same problem, my zlib is built without static libs. Maybe it's possible to hardcode the root folder into the ebuild locally?
This is all about prefix not being honored. add --prefix=/usr/armv7a-unknown-linux-gnueabihf/usr/ , or whatever your prefix may be, on top of the list after 'local myconf=(' in the binutils-libs ebuild, and it should cross-compile just fine. Who do I have to poke to get this fixed? :D
Created attachment 562864 [details, diff] hack for the binutils-libs ebuild this patch makes it cross-compile
I attached a patch, which is merely a nasty hack, just to make things work. The prefix must be added to prevent the compile from linking against the hosts libz.so, and the path for libiberty.h has to be changed as otherwise packages who need that header try to follow a broken symlink, and thus fail. This is the case for llvm. @Sergei Trofimovich - do you think this approach can be replaced with a more sophisticated one, so that it doesn't break the compilation for non cross compile cases?
Passing --prefix is not correct as it will break the assumption of /usr/${CHOST} being a new root. --prefix will hardcode paths from outside root. We need to find what injects absolute paths to libraries and do something about it.
So this means one gets a corrupt binary when doing the cross compile via the --prefix switch from #8?
this could be a fix? https://github.com/gentoo/gentoo/commit/af447daaa84a1e17d862c9917d54c6dcbc47ec75
I don't think so. It should fix binutils-libs installation itself.
It's fixed now for sure, I re-emerged a whole cross-toolchain and cross-emerged binutils and binutils-libs with it (2.31.1-r3)
https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-libs/binutils-libs?id=af447daaa84a1e17d862c9917d54c6dcbc47ec75 was likely the fix.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=226a4ca44920e3b83cd1d5a2e427f13fb3ac4b0a commit 226a4ca44920e3b83cd1d5a2e427f13fb3ac4b0a Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-03-02 19:13:31 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-03-02 19:13:49 +0000 sys-libs/binutils-libs: add bug link for elibtoolize, bug #626402 Reported-by: Coacher Closes: https://bugs.gentoo.org/626402 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/binutils-libs/binutils-libs-2.31.1-r3.ebuild | 2 +- sys-libs/binutils-libs/binutils-libs-2.32.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
A backport to 2.30 isn't going to happen then?
You can looks at a fix from newer versions and craft a patch. If you test and attach the patch I'll be happy to apply it.
how far away are we from stabilization of binutils*:2.31.1-r1? Any major blockers left?
