Created attachment 888339 [details] emerge --info To reproduce on a gcc system CPP="gcc -E" ebuild /var/db/repos/gentoo/sys-libs/glibc/glibc-2.39-r2.ebuild clean configure LLVM systems would be affected by this as glibc forces gcc and this involves setting CPP as well. https://github.com/bminor/glibc/blob/glibc-2.39/configure.ac#L373 The issue is that the abi_x86_32 part of the build is built with abi_x86_64 tooling that would have CET support which glibc rejects for abi_x86_32.
Created attachment 888340 [details] sys-libs/glibc-2.39-r2 build.log (xz compressed)
Created attachment 888341 [details] config.log
I hit this bug over the weekend while doing the Portage profile upgrade to a 23.0 profile as prompted by the recent `::gentoo` repository news item. I hope something can be/get done to fix this issue as soon as feasibly possible. Even after a fix gets provided, however, I don't know if it would be safe to re-sync ebuild repositories while still in the middle of the profile update? > The issue is that the abi_x86_32 part of the build is built with abi_x86_64 tooling that would have CET support which glibc rejects for abi_x86_32. That explains why the issue doesn't go away when I unset `sys-libs/glibc`'s `cet` `USE` flag.
Created attachment 888578 [details, diff] sys-libs/glibc-2.39-r2 ebuild patch
(In reply to Bryce Glover from comment #3) > That explains why the issue doesn't go away when I unset `sys-libs/glibc`'s > `cet` `USE` flag. To workaround you will have to explicitly have EXTRA_ECONF="--disable-cet", its enabled via automagic so that will disable it at least.
(In reply to Bryce Glover from comment #3) > Even after a fix gets provided, however, I don't know if it would be safe to re-sync ebuild repositories while still in the middle of the profile update? It's completely safe, really only step where it would weird at all would be if you did that during the world rebuild as --resume wouldn't like that.
> To workaround you will have to explicitly have EXTRA_ECONF="--disable-cet", its enabled via automagic so that will disable it at least. Thanks, that should get me through my profile update and hold me over until the real fix lands. >> Even after a fix gets provided, however, I don't know if it would be safe to re-sync ebuild repositories while still in the middle of the profile update? > > It's completely safe, really only step where it would weird at all would be if you did that during the world rebuild as --resume wouldn't like that. Thanks; good to know.
(Following up on the discussion from the '#gentoo' channel on LiberaChat IRC.) If I use the environment I made with `EXTRA_ECONF="--disable-cet"` set, I get this build error when attempting to re-`emerge` 'sys-libs/glibc:' ``` ⁝ # (Snipped…) /usr/x86_64-pc-linux-gnu/gcc-bin/13/gcc -m64 -march=native -mtune=native -pipe -O2 -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -nostdlib -nostartfiles -r -o /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os '-Wl,-(' /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/dl-allobjs.os /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/rtld-libc.a -lgcc '-Wl,-)' \ -Wl,-Map,/var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os.map /usr/x86_64-pc-linux-gnu/gcc-bin/13/gcc -m64 -march=native -mtune=native -pipe -O2 -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -Wl,-O2 -Wl,--as-needed -Wl,-z,relro,-z,now -nostdlib -nostartfiles -shared -o /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld.so.new \ -Wl,-z,relro -Wl,-z,nomark-plt -Wl,-z,defs -Wl,-z,now \ -Wl,-z,pack-relative-relocs \ /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os -Wl,--version-script=/var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/ld.map \ -Wl,-soname=ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_open_worker_begin': dl-open.c:(.text+0xb706): undefined reference to `_dl_cet_open_check' /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `_dl_start_user': (.text+0x1a5a4): undefined reference to `_dl_cet_setup_features' /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_main': rtld.c:(.text+0x1d61d): undefined reference to `_dl_cet_check' /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld.so.new: hidden symbol `_dl_cet_open_check' isn't defined /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[2]: *** [Makefile:1332: /var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/ld.so] Error 1 make[2]: Leaving directory '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39/elf' make[1]: *** [Makefile:485: elf/subdir_lib] Error 2 make[1]: Leaving directory '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' make: *** [Makefile:9: all] Error 2 make: Leaving directory '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/build-amd64-x86_64-pc-linux-gnu-nptl' * ERROR: sys-libs/glibc-2.39-r2::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.39-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.39-r2::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' * S: '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' >>> Failed to emerge sys-libs/glibc-2.39-r2, Log file: >>> '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/build.log' * Messages for package sys-libs/glibc-2.39-r2: * ERROR: sys-libs/glibc-2.39-r2::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.39-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.39-r2::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' * S: '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' ``` (Full `emerge` logs forthcoming.)
I don't think further analysis is required. It's just that your GCC is setting -fcf-protection=full by default so EXTRA_ECONF is insufficient, you need to pass -fcf-protection=none or whatever too in *FLAGS, I guess in.
(Apologies for the belated reply.) > I don't think further analysis is required. That's what I was thinking, too: - I was successfully able to build sys-libs/glibc and finish my profile update's final world build by explicitly setting the `-cet` `USE` flag for a few more packages. - I don't consider my (now resolved) issue relevant to this bug discussion thread any more. If you don't need those logs, then I won't collect them.
I can report that I took Alfred's patch to the ebuild as attached to the ticket, and with that I got through the profile update including a full world rebuild without having to change any USE flags. LLVM/libc++ system.
I apologize for the stupid question, but after integrating the patch, should glibc be compiled using gcc or can it be done using clang?
Glibc is hardcoded to be built with gcc (unless you set custom-cflags), this patch doesn't change that.
Why does this error pop up? "ERROR: sys-libs/glibc-2.39-r2::gentoo failed (prepare phase): * patch -p1 failed with /etc/portage/patches/sys-libs/glibc-2.39-r2/glibc-2.39-r2.ebuild.patch * * Call stack: * ebuild.sh, line 136: Called src_prepare * environment, line 3571: Called default * phase-functions.sh, line 872: Called default_src_prepare * phase-functions.sh, line 948: Called __eapi8_src_prepare * environment, line 365: Called eapply_user * environment, line 1365: Called eapply '/etc/portage/patches/sys-libs/glibc-2.39-r2/glibc-2.39-r2.ebuild.patch' * environment, line 1325: Called _eapply_patch '/etc/portage/patches/sys-libs/glibc-2.39-r2/glibc-2.39-r2.ebuild.patch' * environment, line 1263: Called __helpers_die 'patch -p1 failed with /etc/portage/patches/sys-libs/glibc-2.39-r2/glibc-2.39-r2.ebuild.patch' * isolated-functions.sh, line 112: Called die * The specific snippet of code: * die "$@" * * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.39-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.39-r2::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.39-r2/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' * S: '/var/tmp/portage/sys-libs/glibc-2.39-r2/work/glibc-2.39' "
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=39ba3e621469464a59dc7a37e3c41366d7856066 commit 39ba3e621469464a59dc7a37e3c41366d7856066 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-04-13 18:38:11 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-04-13 18:40:53 +0000 sys-libs/glibc: backport CPP fix to 2.38-r11, sync live And fix style to be consistent wrt quoting too. Bug: https://bugs.gentoo.org/927652 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.38-r11.ebuild | 6 ++++++ sys-libs/glibc/glibc-2.39-r2.ebuild | 2 +- sys-libs/glibc/glibc-9999.ebuild | 6 ++++++ 3 files changed, 13 insertions(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=30e32d9ed408fd786e9c1e16063c1228d123ebc1 commit 30e32d9ed408fd786e9c1e16063c1228d123ebc1 Author: Alfred Wingate <parona@protonmail.com> AuthorDate: 2024-04-10 20:36:37 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-04-13 18:40:52 +0000 sys-libs/glibc: export CPP similarily to CC and CXX * This is copies the approach that CC and CXX use, so that the correct abi is used. Otherwise an abi_x86_32 configure test could automagically enable CET which isn't available on abi_x86_32. Bug: https://bugs.gentoo.org/927652 Signed-off-by: Alfred Wingate <parona@protonmail.com> Closes: https://github.com/gentoo/gentoo/pull/36200 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.39-r2.ebuild | 6 ++++++ 1 file changed, 6 insertions(+)
(In reply to WhispByteMe from comment #14) > Why does this error pop up? > "ERROR: sys-libs/glibc-2.39-r2::gentoo failed (prepare phase): > * patch -p1 failed with > /etc/portage/patches/sys-libs/glibc-2.39-r2/glibc-2.39-r2... /etc/portage/patches is for patches to source code, not ebuilds.
*** Bug 928900 has been marked as a duplicate of this bug. ***
