This is extremely inexplicable to me, and I cannot find any logical reason for why this happens. I am building Gentoo prefix in an armv7l environment, running in a qemu-user chroot on an x86 system. (Cursed, yes, but necessary) FWIW, a possibly affecting modification I have made is changing CHOST to armv7a-unknown-linux-gnueabihf, from the default armv7a-softfloat-linux-gnueabi used by bootstrap-prefix.sh, as these are NOT always compatible toolchains - especially with the headers gnu/stubs-soft.h and gnu/stubs-hard.h (a separate bug I ran into) (hard MUST be used on hardfloat, and soft MUST be used on softfloat). Once stage3 was reached, originally, building coreutils pulled in app-admin/perl-cleaner, which pulled in normal (non-prefix) portage before it is meant to be built in in stage3 (this is a separate bug, but could *possibly* be relevant to what I am seeing here). This caused some perl module builds to fail, and perl @INC did NOT have EPREFIX prepended. I hypothesised that portage acts weirdly in this situation, removed that dependency chain, and moved on with the bootstrap. However, the bootstrap then got up to the emerge -uDNv system part of the stage3 bootstrap. There was an issue with libxcrypt not being able to find specific Glibc 2.38 symbols. Upon inspecting some binaries in $EPREFIX/usr/bin, I noticed that every binary built during this emerge -uDNv system command had the incorrect dynamic linker /lib/ld-linux-armhf.so.3. Since my host glibc is 2.37, I think this provides sufficient evidence to conclude that portage is NOT using the correct libc. I have confirmed that; - the glibc rebuild is not the issue. masking the updated version of glibc does NOT alleviate the problem - GCC does(?!) produce a binary with dynamic linker $EPREFIX/lib/ld-linux-armhf.so.3 when invoked normally on a trivial c file. - Portage does(?!!) produce binaries with dynamic linker $EPREFIX/lib/ld-linux-armhf.so.3 when CC (and CXX appropriately) is explicitly set to "gcc --sysroot=$EPREFIX -Wl,--dynamic-linker=$EPREFIX/lib/ld-linux-armhf.so.3" in $EPREFIX/etc/portage/make.conf. This is a HACK not a solution. I cannot currently confirm whether; - the portage rebuild is definitively the issue - the disrespect of EPREFIX extends beyond dynamic linker/libc Please let me know if there are any other ideas :) Will attach emerge --info in a few moments
Created attachment 882078 [details] stage1 log (xz compressed)
Created attachment 882079 [details] stage2 log (xz compressed)
Created attachment 882080 [details] stage3 log part 1 (xz compressed)
Created attachment 882081 [details] stage3 log part 2 (xz compressed)
The toolchain part is likely distinct from whatever is going on with Perl's @INC.
Hmm. Further digging has uncovered a development that might be the source of the problems... (and would explain why this has not been generally hit). stage2 has tmp/etc/portage/make.profile pointing to prefix/linux/arm profile. This profile sets CHOST armv7a-softfloat-linux-gnueabi. (In my case, I changed this to CHOST armv7a-hardfloat-linux-gnueabihf, but I suspect it would occur identically if I didn't change it). portage from stage2 is used for most of stage3, and continues to use that profile. When portage is rebuilt in stage3, it now uses etc/portage/make.profile, which points to a DIFFERENT profile, default/linux/arm/17.0/armv7a/prefix/kernel-3.2+ (I assume there is a good reason for this). This profile sets CHOST armv7a-unknown-linux-gnueabihf! Thus at the point that seems to be the point at which problems begin, CHOST changes!! Which is clearly Very Highly Problematic(TM). I think this is very likely unintentional. From here I will rerun the entire bootstrap with CHOST=armv7a-unknown-linux-gnueabihf the entire way through (won't be able to use an existing snapshot). Let's see how we go :D
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=b0f2edb51723bdc1eb06f5e2e6f2cd8f02f9c057 commit b0f2edb51723bdc1eb06f5e2e6f2cd8f02f9c057 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-01-13 22:56:33 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-01-13 22:56:33 +0000 scripts/bootstrap-prefix.sh: Make Linux CHOST detection less braindead Especially for ARM. Closes: https://bugs.gentoo.org/921927 Signed-off-by: James Le Cuirot <chewi@gentoo.org> scripts/bootstrap-prefix.sh | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=56d6768219f36a0c8a0fce8626c0d2593525d151 commit 56d6768219f36a0c8a0fce8626c0d2593525d151 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-01-20 10:21:32 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-01-20 10:27:18 +0000 profiles: Switch prefix/linux/arm to hardfloat Prefix does not have profiles for ARM generations before armv7a. It currently sets CHOST to a softfloat tuple, but no one uses softfloat on armv7a these days. Inherit default/linux/arm/17.0/armv7a instead of default/linux/arm/17.0 and pick up the hardfloat tuple from there. This fixes RAP bootstrap where it would wrongly switch from softfloat to hardfloat half way through. Note that the 23.0 profiles split out arm7a into sf and hf variants, so we should probably point this prefix profile at the latter when 23.0 is ready. Closes: https://bugs.gentoo.org/921927 Signed-off-by: James Le Cuirot <chewi@gentoo.org> profiles/prefix/linux/arm/make.defaults | 7 ------- profiles/prefix/linux/arm/parent | 2 +- 2 files changed, 1 insertion(+), 8 deletions(-)
