Created attachment 488040 [details] build.log of cross compiled bc-1.07.1 Cross compiling of bc-1.07.1 will fail because it will try to execute `fbc` which is compiled for the target architecture. According to this https://patchwork.openembedded.org/patch/140001/ upstream is already aware and working on 1.07.2 to fix this issue. Using 1.06.x for cross compiles in the mean time.
I encountered the same problem while cross compiling aarch64 too. My workaround was to add aarch64 to QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS in /usr/portage/make.conf. Then I recompiled QEMU and ran the following commands as root: modprobe binfmt_misc echo ':aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-aarch64-wrapper:' > /proc/sys/fs/binfmt_misc/register cat > /usr/local/bin/qemu-aarch64-wrapper << END #!/bin/sh firstarg=${1} shift exec /usr/bin/qemu-aarch64 -L /usr/aarch64-unknown-linux-gnu "${firstarg}" "${@}" END chmod 755 /usr/local/bin/qemu-aarch64-wrapper Then I reran the build and it worked. The idea is to (ab)use QEMU-user's dynamic binary translation to treat the aarch64 binary like a script. :/
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35e6708437937e606a718be756ba8a7988652323 commit 35e6708437937e606a718be756ba8a7988652323 Author: Mike Frysinger <vapier@chromium.org> AuthorDate: 2018-09-18 03:47:29 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2018-09-18 03:48:36 +0000 sys-devel/bc: fix cross-compile builds #627126 Fixes: https://bugs.gentoo.org/627126 sys-devel/bc/bc-1.07.1-r2.ebuild | 3 +++ sys-devel/bc/files/bc-1.07.1-use-system-bc.patch | 16 ++++++++++++++++ 2 files changed, 19 insertions(+)
Hmm. Mike, although it is likely to be installed, bc isn't in @system. Better than nothing I suppose. When we brought HDEPEND into EAPI 7 as BDEPEND, I wanted to include the targetroot USE flag as that would have helped in this case but I was told that ebuilds should bootstrap themselves instead. They were willing to reconsider it after seeing how things pan out but this case probably could be fixed by bootstrapping with a little effort.
