seen with binutils trunk 20220629 building GCC 10, 11, 12 with a profiled lto build. Can be worked around by disabling the GCC lto build, still doing a profiled build. The lto1, gnat1, dm21 executables fail to link with /usr/bin/ld: libcommon.a(input.o): copy relocation against non-copyable protected symbol `__cxa_pure_virtual' collect2: error: ld returned 1 exit status Building GCC trunk without profiled and lto config still shows this, and reverting back to binutils 2.38 lets the build succeed. complete build log for GCC trunk at https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=arm64&ver=1%3A20220630-1&stamp=1656585314&raw=0
also reported as https://gcc.gnu.org/PR106145
caused by 90b7a5df152a64d2bea20beb438e8b81049a5c30 and 4fb55bf6a9606eb7b626c30a9f4e71d6c2d4fbb2
linking lto1 does not fail (in the build log), gnat1 does. i don't know how __cxa_pure_virtual ends up being protected, but the link uses -static-libstdc++ where the definition should be, so copy reloc should not happen and thus the error is wrong. somethings that may help debugging: check `readelf -aW gnat1 |grep __cxa_pure_virtual` after linking with old binutils (is there any reloc? is it protected?) pass -Wl,-y,__cxa_pure_virtual to the failing link (does the definition come from static libstdc++?).
it depends which *1 executable is built first. https://launchpadlibrarian.net/610456289/buildlog_ubuntu-kinetic-arm64.gcc-11_11.3.0-4ubuntu1_BUILDING.txt.gz has failures in f951 and go1, https://launchpadlibrarian.net/610252712/buildlog_ubuntu-kinetic-arm64.gcc-12_12.1.0-5ubuntu1_BUILDING.txt.gz has a failure in dm21 I'm sure I saw a failure on lto1 too, but it looks there's some randomness which of these is built first.
(In reply to Matthias Klose from comment #4) > it depends which *1 executable is built first. > > https://launchpadlibrarian.net/610456289/buildlog_ubuntu-kinetic-arm64.gcc- > 11_11.3.0-4ubuntu1_BUILDING.txt.gz > has failures in f951 and go1, > > https://launchpadlibrarian.net/610252712/buildlog_ubuntu-kinetic-arm64.gcc- > 12_12.1.0-5ubuntu1_BUILDING.txt.gz > has a failure in dm21 > > I'm sure I saw a failure on lto1 too, but it looks there's some randomness > which of these is built first. As nsz' commention suggests, -Wl,-y,__cxa_pure_virtual information (and then run `readelf -sW` on the defining archive/object) is needed. The logs are not useful.
sorry i don't know what is "a profiled lto build" i tried using debian g++-12 in a container with new binutils doing a normal build with same config as seen in the build log. (did not apply the debian gcc patches) with that i cannot reproduce the issue, in gnat1 i see 134: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __cxa_pure_virtual i.e. no definition of __cxa_pure_virtual gets linked. if "profiled lto build" behaves differently then this sounds like a profiled lto gcc bug. can it be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
a profiled lto GCC build: - configure with -with-build-config=bootstrap-lto-lean - build with: make profiledbootstrap
still cannot reproduce it, the gcc i used for the build was gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/work/bgcc/install/libexec/gcc/aarch64-linux-gnu/12/lto-wrapper Target: aarch64-linux-gnu Configured with: /work/bgcc/src/gcc-12/configure -v --enable-languages=c,ada,c++ --prefix=/work/bgcc/install --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=yes,extra,rtl --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.1 20220705 (GCC) and i built a trunk gcc with trunk binutils. gnat1 has only weak refs to __cxa_pure_virtual (the gnat1 link command is the same as the failed cmd in the build log). i dont have more ideas how to move forward with this.
and I cannot reproduce that anymore with updated binutils and gcc builds. closing