| Summary: | after portage rebuild in stage3, EPREFIX does not appear to be respected in some scenarios | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | fosslinux |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | chewi |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
stage1 log (xz compressed)
stage2 log (xz compressed) stage3 log part 1 (xz compressed) stage3 log part 2 (xz compressed) |
||
|
Description
fosslinux
2024-01-12 10:01:52 UTC
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(-) |
