If sys-libs/binutils-libs is installed, attempting to build cross-binutils creates a broken assembler which fails to run, because the assembler binary is incorrectly linked to the copy of lib{opcodes,bfd}.so in /usr/lib (for the host) rather than the one in the target-specific install directory: $ arm-unknown-linux-gnueabi-as Assembler messages: Fatal error: selected target format 'elf32-littlearm' unknown $ ldd /usr/bin/arm-unknown-linux-gnueabi-as linux-vdso.so.1 (0x00007ffe3f90b000) libopcodes-2.25.1.so => /usr/lib64/libopcodes-2.25.1.so (0x00007f4bb021d000) libbfd-2.25.1.so => /usr/lib64/libbfd-2.25.1.so (0x00007f4bafef4000) libz.so.1 => /lib64/libz.so.1 (0x00007f4bafcde000) libc.so.6 => /lib64/libc.so.6 (0x00007f4baf941000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f4baf73d000) /lib64/ld-linux-x86-64.so.2 (0x00007f4bb05a4000) Note that installing binutils-libs by itself does not cause any problems; the breakage occurs when trying to build a new cross-binutils when binutils-libs is already installed. I had thought that the problem could be worked around by uninstalling binutils-libs, building cross-binutils, then reinstalling binutils-libs, but that doesn't seem to work; the resulting executable still attempts to link to libraries in /usr/lib, thus failing to load due to missing libraries. Since cross-*/binutils are just symlinks to sys-devel/binutils, I also suspect that if the host binutils has been rebuilt in the presence of binutils-libs, uninstalling binutils-libs would break the toolchain entirely (though I'm not about to test this on my own system).
Created attachment 413958 [details] emerge-info.txt emerge --info
Created attachment 413960 [details] build.log Build log for cross-arm-unknown-linux-gnueabi/binutils (with binutils-libs installed)
Created attachment 413962 [details] no-binutils-libs-build.log Build log for cross-arm-unknown-linux-gnueabi/binutils (after uninstalling binutils-libs)
Do you have LD_LIBRARY_PATH is your environment?
(In reply to Alexander Tsoy from comment #4) > Do you have LD_LIBRARY_PATH is your environment? No, I don't.
Probably a bug in binutils-config-5. Missing symlinks in /usr/${HOST}/${TARGET}/lib: # objdump -p /usr/bin/armv7a-hardfloat-linux-gnueabi-as | grep PATH RUNPATH /usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib # ls -l /usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib total 4 lrwxrwxrwx 1 root root 67 Oct 8 09:38 ldscripts -> /usr/lib64/binutils/armv7a-hardfloat-linux-gnueabi/2.25.1/ldscripts
Created attachment 414046 [details, diff] binutils-config-5.patch Attached patch works for me.
The patch works for me as well, thanks.
Aplying patch and rebuilding binutils works for my.
Created attachment 414948 [details, diff] binutils-config-5.patch Better patch. Github pull request: https://github.com/gentoo/gentoo/pull/267
*** Bug 564514 has been marked as a duplicate of this bug. ***
*** Bug 564580 has been marked as a duplicate of this bug. ***
Fix also works for me: after applying the patch in #10 and emerging binutils-config-5-r2, crossdev is usable again (targets: armv5tel-softfloat-linux-gnueabi and powerpc-e300c3-linux-gnu, --stable). crossdev was previously dying at "Emerging cross-gcc-stage1 ..." every time.
this is because the bfd build does: # libbfd.a is a host library containing target dependent code bfdlibdir='$(libdir)' bfdincludedir='$(includedir)' if test "${host}" != "${target}"; then bfdlibdir='$(exec_prefix)/$(host_noncanonical)/$(target_noncanonical)/lib' bfdincludedir='$(exec_prefix)/$(host_noncanonical)/$(target_noncanonical)/include' fi so even though we took care of setting up proper libdir/includedir paths for the cross-compiler, the bfd build went ahead and ignored those on us. all of this comes from: https://www.sourceware.org/ml/binutils/2002-05/msg00184.html
newer binutils builds are fixed by: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03d8ab7d71176b80b20abb3309be3c294717676e existing builds are automatically detected and will warn users, but also keep around the old symlinks until they rebuild. we still don't want to use these paths with newer builds, so making it unconditional (i.e. reverting to previous behavior) isn't the route we want to take. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7fbeab2ed7339b602b134a2bba4016e977266a54
*** Bug 563024 has been marked as a duplicate of this bug. ***
*** Bug 563754 has been marked as a duplicate of this bug. ***
*** Bug 564614 has been marked as a duplicate of this bug. ***
Hi! I have file collisions cross-emerging gcc-5.2.0: (target i686-gentoo-linux-gnu): >>> Installing (1 of 1) cross-i686-gentoo-linux-gnu/gcc-5.2.0::local * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). See * http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to * solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * Detected file collision(s): * * /usr/lib64/libcc1.la * /usr/lib64/libcc1.so.0.0.0 * /usr/lib64/libcc1.so * /usr/lib64/libcc1.so.0 * * Searching all installed packages for file collisions... * is it related or an other bug ?
Cross-toolchains seem to work properly now after rebuilding with the fixed eclass, even using unpatched binutils-config. Thanks for the fix! (In reply to Xavier Miller from comment #19) >I have file collisions cross-emerging gcc-5.2.0: (target i686-gentoo-linux-gnu): This bug is for binutils, so that's a separate bug. Though it might have a similar root cause, who knows.
(In reply to Xavier Miller from comment #19) > ... > is it related or an other bug ? It's a bug 547754
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35db5bfb5ce3af08ad8181c657a7b4f81c9dfe3b commit 35db5bfb5ce3af08ad8181c657a7b4f81c9dfe3b Author: Benda Xu <heroxbd@gentoo.org> AuthorDate: 2018-04-13 03:56:34 +0000 Commit: Benda Xu <heroxbd@gentoo.org> CommitDate: 2018-04-13 03:59:56 +0000 sys-devel/binutils-config: revert accidental commit in 62c75f76eb. I have made a mistake to overwrite changes to binutils-config-5. Suggested-By: slyfox Bug: https://bugs.gentoo.org/531616 Bug: https://bugs.gentoo.org/562460 Package-Manager: Portage-2.3.28, Repoman-2.3.9 sys-devel/binutils-config/files/binutils-config-5 | 15 ++++++++++++--- sys-devel/binutils-config/files/binutils-config-5.1 | 15 ++++++++++++--- 2 files changed, 24 insertions(+), 6 deletions(-)}
Nice, but the ebuild is not revbumped, so the update is not applied on installed systems... (In reply to Larry the Git Cow from comment #22) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=35db5bfb5ce3af08ad8181c657a7b4f81c9dfe3b > > commit 35db5bfb5ce3af08ad8181c657a7b4f81c9dfe3b > Author: Benda Xu <heroxbd@gentoo.org> > AuthorDate: 2018-04-13 03:56:34 +0000 > Commit: Benda Xu <heroxbd@gentoo.org> > CommitDate: 2018-04-13 03:59:56 +0000 > > sys-devel/binutils-config: revert accidental commit in 62c75f76eb. > > I have made a mistake to overwrite changes to binutils-config-5. > > Suggested-By: slyfox > Bug: https://bugs.gentoo.org/531616 > Bug: https://bugs.gentoo.org/562460 > Package-Manager: Portage-2.3.28, Repoman-2.3.9 > > sys-devel/binutils-config/files/binutils-config-5 | 15 ++++++++++++--- > sys-devel/binutils-config/files/binutils-config-5.1 | 15 ++++++++++++--- > 2 files changed, 24 insertions(+), 6 deletions(-)}
