/var/tmp/portage/sys-libs/glibc-2.34-r4/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os -Wl,--version-script=/var/tmp/portage/sys-libs/glibc-2.34-r4/work/build-amd64-x86_64-pc-linux-gnu-nptl/ld.map \ -Wl,-soname=ld-linux-x86-64.so.2 \ -Wl,-defsym=_begin=0 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.34-r4/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_main': rtld.c:(.text+0x3837): undefined reference to `_dl_cet_check' /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.34-r4/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_open_worker_begin': dl-open.c:(.text+0x140e6): undefined reference to `_dl_cet_open_check' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no_multilib_hardened-j4-20220102-153509 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.2.1 * Python 3.9.9 php cli: HEAD of ::gentoo commit 9d9ceadaf186e93ea97ad6682f28f8f201e5ef9c Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Jan 2 14:51:51 2022 +0000 2022-01-02 14:51:49 UTC emerge -qpvO sys-libs/glibc [ebuild U ] sys-libs/glibc-2.34-r4 [2.33-r7] USE="caps* clone3%* multiarch nscd* (ssp) (static-libs) -audit -cet -compile-locales (-crypt) -custom-cflags -doc -gd -headers-only (-multilib) -multilib-bootstrap -profile (-selinux) -static-pie -suid -systemd -systemtap -test (-vanilla)"
Created attachment 761083 [details] emerge-info.txt
Created attachment 761084 [details] emerge-history.txt
Created attachment 761085 [details] environment
Created attachment 761086 [details] etc.portage.tar.bz2
Created attachment 761087 [details] logs.tar.bz2
Created attachment 761088 [details] sys-libs:glibc-2.34-r4:20220102-162357.log.bz2
Created attachment 761089 [details] temp.tar.bz2
[03:15:11] <@sam_> gyakovlev: do I remember you hitting 'checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.' on a non-cross build recently? [03:17:21] <@sam_> hmmm [03:17:30] <@sam_> dpaste.com/CXQTNJ5DW [03:18:07] <+gyakovlev> sam_: in my case it was broken xgcc [03:18:17] <+gyakovlev> which was failing conftests [03:18:31] <+gyakovlev> it just a confusing message, actual error should be above in the log [03:18:42] <@sam_> oh i think i know the problem [03:19:10] <+gyakovlev> conftest.c:90:20: error: expected expression before ')' token [03:19:10] <+gyakovlev> 90 | if (sizeof ((pid_t))) [03:21:39] <@sam_> i think old patchset was on mirrors [03:21:45] <@sam_> from when i temporarily used '2' and backed it out [03:22:08] <@sam_> which explains how toralf hit a bug earlier too if you sync and rebuild gcc, does this stop happening?
I do still get at that image: /var/tmp/portage/sys-libs/glibc-2.34-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os -Wl,--version-script=/var/tmp/portage/sys-libs/glibc-2.34-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/ld.map \ -Wl,-soname=ld-linux-x86-64.so.2 \ -Wl,-defsym=_begin=0 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.34-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_main': rtld.c:(.text+0x3837): undefined reference to `_dl_cet_check' /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.34-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_open_worker_begin': dl-open.c:(.text+0x140e6): undefined reference to `_dl_cet_open_check'
emerge --info gcc?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0c6762824e9e51b962a9ca0385448c7b08093f7 commit a0c6762824e9e51b962a9ca0385448c7b08093f7 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-07 00:36:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-07 00:40:14 +0000 sys-devel/gcc: CET support needs glibc[cet] if enabled We'll probably revbump with these fixes (or a slightly later gcc snapshot) shortly, but not doing it just yet. Bug: https://bugs.gentoo.org/830454 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-11.2.1_p20211127.ebuild | 4 ++-- sys-devel/gcc/gcc-11.2.1_pre9999.ebuild | 4 ++-- sys-devel/gcc/gcc-12.0.0_pre9999.ebuild | 7 ++++--- 3 files changed, 8 insertions(+), 7 deletions(-)
commit a0c6762824e9e51b962a9ca0385448c7b08093f7 (HEAD -> master, origin/master, origin/HEAD) Author: Sam James <sam@gentoo.org> Date: Fri Jan 7 00:36:10 2022 +0000 sys-devel/gcc: CET support needs glibc[cet] if enabled We'll probably revbump with these fixes (or a slightly later gcc snapshot) shortly, but not doing it just yet. Bug: https://bugs.gentoo.org/830454 Signed-off-by: Sam James <sam@gentoo.org> commit c159caed310ded6e6692cae855e049033a4fc192 Author: Sam James <sam@gentoo.org> Date: Fri Jan 7 00:36:10 2022 +0000 sys-devel/gcc: CET support needs glibc[cet] if enabled We'll probably revbump with these fixes (or a slightly later gcc snapshot) shortly, but not doing it just yet. Bug: https://bugs.gentoo.org/830454 Signed-off-by: Sam James <sam@gentoo.org> ... I think this should help. We now need glibc and binutils support for CET. The binutils one is negotiable but we already BDEPEND on binutils anyway, so let's stick with it for nwo.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac1a83da759184984512e1becf8eb9cbc129c157 commit ac1a83da759184984512e1becf8eb9cbc129c157 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-07 00:42:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-07 00:42:36 +0000 sys-devel/gcc: tweak/simplify *DEPEND Bug: https://bugs.gentoo.org/830454 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-11.2.1_p20211127.ebuild | 3 ++- sys-devel/gcc/gcc-11.2.1_pre9999.ebuild | 3 ++- sys-devel/gcc/gcc-12.0.0_pre9999.ebuild | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-)
Created attachment 761471 [details] emerge--info-gcc.txt emerge--info-gcc.txt
(In reply to Toralf Förster from comment #14) > Created attachment 761471 [details] > emerge--info-gcc.txt > > emerge--info-gcc.txt If you rebuild gcc now, it should force CET USE on for glibc and binutils. Does this error then go away?
(In reply to Sam James from comment #15) > If you rebuild gcc now, it should force CET USE on for glibc and binutils. > Does this error then go away? yes.
I have the same problem with glibc on Gentoo Hardened: I have the same problem with glibc (2.33-r13, 2.34-r10) on Gentoo Hardened: x86_64-pc-linux-gnu-gcc -m32 -march=native -fstack-clash-protection -fcf-protection=full -pipe -Wl,-O1 -Wl,--as-needed -O2 -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -nostdlib -nostartfiles -r -o /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/librtld.os '-Wl,-(' /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/dl-allobjs.os /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/rtld-libc.a -lgcc '-Wl,-)' \ -Wl,-Map,/var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/librtld.os.map x86_64-pc-linux-gnu-gcc -m32 -march=native -fstack-clash-protection -fcf-protection=full -pipe -Wl,-O1 -Wl,--as-needed -O2 -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--as-needed -nostdlib -nostartfiles -shared -o /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/ld.so.new \ -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,defs -Wl,-z,now \ /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/librtld.os -Wl,--version-script=/var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/ld.map \ -Wl,-soname=ld-linux.so.2 \ -Wl,-defsym=_begin=0 /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `.L467': rtld.c:(.text+0x3500): undefined reference to `_dl_cet_check' /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/librtld.os: in function `dl_open_worker': dl-open.c:(.text+0x13b66): undefined reference to `_dl_cet_open_check' /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-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/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[2]: *** [Makefile:586: /var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl/elf/ld.so] Error 1 make[2]: Leaving directory '/var/tmp/portage/sys-libs/glibc-2.33-r13/work/glibc-2.33/elf' make[1]: *** [Makefile:480: elf/subdir_lib] Error 2 make[1]: Leaving directory '/var/tmp/portage/sys-libs/glibc-2.33-r13/work/glibc-2.33' make: *** [Makefile:9: all] Error 2 make: Leaving directory '/var/tmp/portage/sys-libs/glibc-2.33-r13/work/build-x86-x86_64-pc-linux-gnu-nptl' * ERROR: sys-libs/glibc-2.33-r13::gentoo failed (compile phase): * emake failed *
Created attachment 769223 [details] Emerge --info
Created attachment 769226 [details] sys-libs:glibc-2.33-r13:20220406-215452.log.bz2 sys-libs:glibc-2.33-r13:20220406-215452.log
Created attachment 769229 [details] sys-libs:glibc-2.34-r10:20220406-214735.log.bz2 sys-libs:glibc-2.34-r10:20220406-214735.log
The cause of my problem with glibc is the following function: # Enable Intel Control-flow Enforcement Technology on amd64 if requested case ${CTARGET} in x86_64-*) myconf+=( $(use_enable cet) ) ;; *) ;; esac After hashing this function glibc builds and works correctly. This function is found on lines 918-922 in glibc-2.33-r13.ebuild. https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-libs/glibc/glibc-2.33-r13.ebuild Cheers ;)
(In reply to Jacekalex from comment #21) > The cause of my problem with glibc is the following function: > > # Enable Intel Control-flow Enforcement Technology on amd64 if requested > case ${CTARGET} in > x86_64-*) myconf+=( $(use_enable cet) ) ;; > *) ;; > esac > > After hashing this function glibc builds and works correctly. > You mean commenting out? This is self-inflicted by your *FLAGS, I think. In future, do open a new bug please, as it's harder to miss then. We should have a filter-flags and control entirely via use_enable. It's not safe to build glibc with -fcf-protection=full entirely, and the configure option handles it when it's safe to do so (exactly like PIE, SSP, ...). Please ensure USE=cet in make.conf.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=256df48ff6e85ffa389cc2d25453d100279b62fe commit 256df48ff6e85ffa389cc2d25453d100279b62fe Author: Sam James <sam@gentoo.org> AuthorDate: 2022-04-07 19:51:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-07 19:51:59 +0000 sys-libs/glibc: filter -fcf-protection Set USE=cet if you want this. glibc can't be built with this *everywhere*, and the configure option (controlled by USE=cet) sets it for the components for which it works. It's just like SSP and PIE. You can't force it on all of glibc, and we have mechanisms to do it properly (USE=cet). Closes: https://bugs.gentoo.org/830454 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.34-r11.ebuild | 3 +++ sys-libs/glibc/glibc-2.35-r2.ebuild | 3 +++ sys-libs/glibc/glibc-9999.ebuild | 3 +++ 3 files changed, 9 insertions(+)
Hi Intel CET technology only supports Intel Tiger Lake and Alder Lake, earlier versions of Intel processors still in use, do not support CET. You need to be able to effectively disable CET in GCC, GlibC and other programs, or create an eclass that checks for CET support in the CPU. https://newsroom.intel.com/editorials/intel-cet-answers-call-protect-common-malware-threats/ Cheers
(In reply to Jacekalex from comment #24) > Hi > > Intel CET technology only supports Intel Tiger Lake and Alder Lake, earlier > versions of Intel processors still in use, do not support CET. > You need to be able to effectively disable CET in GCC, GlibC and other > programs, or create an eclass that checks for CET support in the CPU. > This doesn't actually matter. The instructions which CET *uses* are available in i686+ (even on x86!). They just do nothing at runtime for CET purposes on < Tiger Lake. But your comment has no effect on whether the filter-flags is correct anyway (it is), and we have USE=cet if people want to disable it anyway. Again though, it does nothing and is safe even on CPUs without it.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a389baf98dd67ea9b1f22acb2aa227543ff88e9d commit a389baf98dd67ea9b1f22acb2aa227543ff88e9d Author: Sam James <sam@gentoo.org> AuthorDate: 2022-04-10 10:54:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-10 10:54:00 +0000 sys-libs/glibc: add filter-flags for CET to 2.34-r10 too May as well add it to the stable one as lots of people seem to be shoving this in CFLAGS in make.conf now and don't want more dupes. See 256df48ff6e85ffa389cc2d25453d100279b62fe for more background. Bug: https://bugs.gentoo.org/830454 See: 256df48ff6e85ffa389cc2d25453d100279b62fe Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.34-r10.ebuild | 3 +++ 1 file changed, 3 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0b7eace724b0035856311008c95cc7fe18b8231b commit 0b7eace724b0035856311008c95cc7fe18b8231b Author: Krzesimir Nowak <knowak@microsoft.com> AuthorDate: 2023-03-17 02:34:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-17 02:35:53 +0000 sys-libs/glibc: disable CET explicitly if USE=-cet When bootstrapping, we may have a situation where CET-enabled gcc from seed is used to build CET-disabled glibc. As such, gcc implicitly enables CET if no -fcf-protection flag is passed. For a typical package it should not be a problem, but for glibc it matters as it is dealing with CET in ld.so. So if CET is supposed to be disabled for glibc, be explicit about it. [sam: cherry-picked from Flatcar at https://github.com/flatcar/coreos-overlay/commit/f4b92a6de9fcf506b30f1c6156b27c0e3d25438e] Bug: https://bugs.gentoo.org/830454 Closes: https://bugs.gentoo.org/901363 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.36-r7.ebuild | 13 ++++++++++++- sys-libs/glibc/glibc-2.37-r1.ebuild | 13 ++++++++++++- sys-libs/glibc/glibc-9999.ebuild | 13 ++++++++++++- 3 files changed, 36 insertions(+), 3 deletions(-)
