Summary: | sys-libs/glibc-2.32-r7: cannot bootstrap on Arch Linux that has glibc-2.33 | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Joey Dumont <joey.dumont> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Joey Dumont
2021-02-13 01:34:00 UTC
Thanks Joey, do you have the build.log of sys-libs/glibc? That will tell the root cause of this bug. Oops, sorry, forgot to link it: https://drive.google.com/file/d/1mBeEDBxno8g6fRnrOE6LdB9VxWj7Hb2J/view?usp=sharing It's 20MB large, so unfortunately it needs to be externally linked. So, the stage2 libstdc++ picks up symbols from the host libc that are not in the libc version that we are trying to boostrap. In short: $ objdump -T /usr/lib64/libc.so.6 | grep "GLIBC.*fstat" 00000000000ef570 w DF .text 0000000000000032 GLIBC_2.33 fstatat 00000000000ef960 w DF .text 0000000000000025 GLIBC_2.2.5 fstatfs 00000000000efa10 w DF .text 000000000000006c GLIBC_2.2.5 fstatvfs 00000000000ef530 w DF .text 0000000000000018 GLIBC_2.33 fstat 00000000000ef960 w DF .text 0000000000000025 GLIBC_2.2.5 fstatfs64 00000000000ef530 w DF .text 0000000000000018 GLIBC_2.33 fstat64 00000000000efa10 w DF .text 000000000000006c GLIBC_2.2.5 fstatvfs64 00000000000ef530 g DF .text 0000000000000018 GLIBC_PRIVATE __fstat64 00000000000ef570 w DF .text 0000000000000032 GLIBC_2.33 fstatat64 objdump -T /cvmfs/software.dumont.ca/2021.02/compat/linux/x86_64/var/tmp/portage/sys-libs/glibc-2.32-r7/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so |grep "GLIBC.*fstat" 00000000000ed2a0 w DF .text 0000000000000021 GLIBC_2.2.5 fstatfs 00000000000ed340 w DF .text 000000000000006c GLIBC_2.2.5 fstatvfs 00000000000ed2a0 w DF .text 0000000000000021 GLIBC_2.2.5 fstatfs64 00000000000ed340 w DF .text 000000000000006c GLIBC_2.2.5 fstatvfs64 When trying to emerge glibc, rpath-link is set to EPREFIX/var/tmp/portage/sys-libs/glibc-2.32-r7/work/build-amd64-x86_64-pc-linux-gnu-nptl/libc.so, so the linker is trying to use the newly built libc.so to link crtn.o. I'm not sure what the fix is. I've been reading online that glibc doesn't really support bootstrapping an older glibc from a newer one. Maybe statically linking the stage2 libstdc++? I tried the workaround in https://bugs.gentoo.org/702342#c13, as I thought the issue was similar, but I got the same error. There's only one fix, and that is using glibc-2.33. (It'll go into ~arch soon.) Thank you, that's what I suspected when I first opened the bug report. I was hoping there was some kind of magic to fix it. Should I confirm that bootstrap works as expected when 2.33 lands on ~arch before we close this, or do you want to close it now? Error is reproducible on my Artix Linux machine as well. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=403201568d69cb5d00cedfb8799ef8a12e239d0c commit 403201568d69cb5d00cedfb8799ef8a12e239d0c Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2021-04-03 09:29:12 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2021-04-03 09:29:39 +0000 sys-libs/glibc: Re-keyword 2.33 Closes: https://bugs.gentoo.org/770334 Bug: https://bugs.gentoo.org/769989 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Andreas K. Huettel <dilfridge@gentoo.org> sys-libs/glibc/glibc-2.33.ebuild | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) |