gcc -o /home/dave/gnu/glibc/objdir/debug/tst-fortify-cc-default-1 -nostdlib -nos tartfiles -Wl,-z,relro /home/dave/gnu/glibc/objdir/csu/crt1.o /home/dave/gn u/glibc/objdir/csu/crti.o `gcc --print-file-name=crtbegin.o` /home/dave/gnu/gli bc/objdir/debug/tst-fortify-cc-default-1.o /home/dave/gnu/glibc/objdir/support/l ibsupport_nonshared.a -lstdc++ -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-rpath-link= /home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glib c/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/ home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/gli bc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir /support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl -lgc c -Wl,--as-needed -lgcc_s -Wl,--no-as-needed /home/dave/gnu/glibc/objdir/libc.s o.6 /home/dave/gnu/glibc/objdir/libc_nonshared.a -Wl,--as-needed /home/dave/gnu/ glibc/objdir/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s -Wl,--n o-as-needed `gcc --print-file-name=crtend.o` /home/dave/gnu/glibc/objdir/csu/cr tn.o /home/dave/opt/gnu/bin/ld: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongn u-3.o: in function `memcpy': /home/dave/gnu/glibc/glibc/debug/../string/bits/string_fortified.h:30: undefined reference to `__builtin_dynamic_object_size' /home/dave/opt/gnu/bin/ld: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongn u-3.o: in function `memmove': /home/dave/gnu/glibc/glibc/debug/../string/bits/string_fortified.h:37: undefined reference to `__builtin_dynamic_object_size' /home/dave/opt/gnu/bin/ld: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongn u-3.o: in function `memcpy': /home/dave/gnu/glibc/glibc/debug/../string/bits/string_fortified.h:30: undefined reference to `__builtin_dynamic_object_size' /home/dave/opt/gnu/bin/ld: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongnu-3.o: in function `bcopy': /home/dave/gnu/glibc/glibc/debug/../string/bits/strings_fortified.h:26: undefined reference to `__builtin_dynamic_object_size' /home/dave/opt/gnu/bin/ld: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongnu-3.o: in function `memcpy': /home/dave/gnu/glibc/glibc/debug/../string/bits/string_fortified.h:30: undefined reference to `__builtin_dynamic_object_size' /home/dave/opt/gnu/bin/ld: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongnu-3.o:/home/dave/gnu/glibc/glibc/debug/../string/bits/string_fortified.h:60: more undefined references to `__builtin_dynamic_object_size' follow collect2: error: ld returned 1 exit status make[2]: *** [../Rules:238: /home/dave/gnu/glibc/objdir/debug/tst-fortify-c-nongnu-3] Error 1 dave@atlas:~/gnu/glibc/objdir$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/dave/opt/gnu/gcc/gcc-12a/libexec/gcc/hppa-linux-gnu/12.0.0/lto-wrapper Target: hppa-linux-gnu Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-multiarch --enable-linker-build-id --build=hppa-linux-gnu --host=hppa-linux-gnu --target=hppa-linux-gnu --prefix=/home/dave/opt/gnu/gcc/gcc-12a --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu --enable-checking=release --enable-languages=c,c++ --without-ppl --enable-libssp --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20211008 (experimental) [master r13-1220-g7c1c7e120cc] (GCC) Breaks testsuite.
(In reply to John David Anglin from comment #0) > gcc version 12.0.0 20211008 (experimental) [master r13-1220-g7c1c7e120cc] > (GCC) That looks like a GCC snapshot that's just too old. The version-based header conditionals work only with released compilers (and later stage 4 snapshots because of the development wind-down).
On 2022-08-07 4:43 a.m., fweimer at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=29452 > > Florian Weimer <fweimer at redhat dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Flags| |security- > Status|NEW |WAITING > CC| |fweimer at redhat dot com > > --- Comment #1 from Florian Weimer <fweimer at redhat dot com> --- > (In reply to John David Anglin from comment #0) >> gcc version 12.0.0 20211008 (experimental) [master r13-1220-g7c1c7e120cc] >> (GCC) > That looks like a GCC snapshot that's just too old. The version-based header > conditionals work only with released compilers (and later stage 4 snapshots > because of the development wind-down). This appeared bisecting gcc to find which revision introduced the failure of malloc/tst-scratch_buffer on hppa: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
On 2022-08-07 4:43 a.m., fweimer at redhat dot com wrote: > --- Comment #1 from Florian Weimer <fweimer at redhat dot com> --- > (In reply to John David Anglin from comment #0) >> gcc version 12.0.0 20211008 (experimental) [master r13-1220-g7c1c7e120cc] >> (GCC) > That looks like a GCC snapshot that's just too old. The version-based header > conditionals work only with released compilers (and later stage 4 snapshots > because of the development wind-down). Shouldn't the prereq for __builtin_dynamic_object_size be GCC 12.1 instead of 12.0? There's no 12.0 release and the feature was added during the development phase for the first GCC 12 release.
(In reply to dave.anglin from comment #3) > Shouldn't the prereq for __builtin_dynamic_object_size be GCC 12.1 instead > of 12.0? > > There's no 12.0 release and the feature was added during the development > phase for the > first GCC 12 release. AFAICT, except for one instance (in a test not in any headers), version checks against the first major release always refer to the .0 version number. I guess this is to make the feature testable during development (where one simply rebases to the latest gcc development snapshot) so that it remains unchanged in glibc even after release.
I have found (kind of) a similar problem. I was using nvcc-8 on Ubuntu22, and after some glibc package upgrades, it stopped working. (see https://stackoverflow.com/questions/76531467/nvcc-cuda8-gcc-5-3-no-longer-compiles-with-o1-on-ubuntu-22-04). Now getting: /usr/include/x86_64-linux-gnu/bits/string_fortified.h(104): error: identifier "__builtin___stpncpy_chk" is undefined I was wondering if there is a way to hack 'by hand' the string_fortified.h with an #ifdef guard that checks for the CUDA_version... to restore the original behavior before the package upgrade. Thanks!
(In reply to ferdymercury from comment #5) > I have found (kind of) a similar problem. I was using nvcc-8 on Ubuntu22, > and after some glibc package upgrades, it stopped working. (see > https://stackoverflow.com/questions/76531467/nvcc-cuda8-gcc-5-3-no-longer- > compiles-with-o1-on-ubuntu-22-04). > > Now getting: /usr/include/x86_64-linux-gnu/bits/string_fortified.h(104): > error: identifier "__builtin___stpncpy_chk" is undefined > > I was wondering if there is a way to hack 'by hand' the string_fortified.h > with an #ifdef guard that checks for the CUDA_version... to restore the > original behavior before the package upgrade. > > Thanks! This looks like something we fixed in 2.36 and backported to the 2.35 release branch: https://sourceware.org/git/?p=glibc.git;a=commit;h=478cd506eaa5bbc81e3de6593a5064fa5f36fea9 Ubuntu needs to rebase its release or at least cherry-pick that fix.
Thanks so much for the swift reply. I cherry picked this commit locally, but it was not enough, I also had to add the following to the ifdef, so that it entered into the "else", because I am using nvcc-8 compiler together with gcc (Ubuntu 5.3.1-14ubuntu2): # if (__GNUC_PREREQ (4, 7) && (!defined(CUDART_VERSION) || CUDART_VERSION>8000)) || __glibc_clang_prereq (2, 6) Now it's working, thanks so much for the hint!