I downloaded gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu.tar.xz and attempted to check which symbol versions the included libstdc++.so.6 provided:
$ ./gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-objdump -T \ gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/lib64/libstdc++.so.6.0.28 \ |grep -v '*UND*'|headgcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/lib64/libstdc++.so.6.0.28: file format elf64-littleaarch64DYNAMIC SYMBOL TABLE:00000000000b4568 l d .init 0000000000000000 .init0000000000208728 l d .data 0000000000000000 .data00000000001054c8 w DF .text 000000000000000c Base _ZNKSbIwSt11char_traitsIwESaIwEE8capacityEv0000000000201650 w DO .data.rel.ro 0000000000000068 Base _ZTVNSt7__cxx1117moneypunct_bynameIwLb0EEE0000000000101c80 w DF .text 0000000000000014 Base _ZNSsC1Ev00000000001734c0 w DF .text 0000000000000048 Base _ZNSt10filesystem7__cxx114pathD2Ev
All of the C++ symbols have version "Base" rather the expected values such as GLIBCXX_3.4.28 or CXXABI_1.3.12. Can anyone explain why they're missing from the library?
If I run the same objdump command on the libstdc++.so.6.* that's shipped with Ubuntu 20.04 (either x86-64 or AArch64), then all the symbols *do* have versions as expected. The same has been true for the libstdc++.so.* included in Linaro toolchains in the past. For example:
$ aarch64-linux-gnu-objdump -T ./usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28|grep -v '*UND*'|head./usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28: file format elf64-littleDYNAMIC SYMBOL TABLE:00000000000f0890 w DF .text 000000000000000c GLIBCXX_3.4 _ZNKSbIwSt11char_traitsIwESaIwEE8capacityEv00000000001d6840 w DO .data.rel.ro 0000000000000068 GLIBCXX_3.4.21 _ZTVNSt7__cxx1117moneypunct_bynameIwLb0EEE00000000000ed620 w DF .text 0000000000000013 GLIBCXX_3.4 _ZNSsC1Ev000000000015a0b0 w DF .text 0000000000000021 GLIBCXX_3.4.21 _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv000000000011e160 w DF .text 0000000000000024 GLIBCXX_3.4 _ZNSt9money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEED0Ev000000000018b4f8 g DO .rodata 0000000000000001 GLIBCXX_3.4 _ZNSt14numeric_limitsIjE15tinyness_beforeE
This is important so that the compiled code generated by the compiler/linker correctly encodes which symbol versions it relies upon, and hence the dynamic linker won't allow it to run on systems with an incompatible libstdc++.so.
I followed the build instructions in the release notes on the download website. All copies of libstdc++.so.6.0.28 that are generated by the build process DO have the symbol versions that I expect to be present. It seems like there's some post-processing step that isn't listed in the build instructions.
Notes for anyone who wants to repro this, on Ubuntu 20.04:
1) I used git commit 43664e2dbd31 of the abe tool; this matches the date the toolchain on the website was built.
2) I had to add a script named "python" into $PATH, which simply execs /usr/bin/python2 "$@"
3) I had to add /usr/share/doc/git/contrib/workdir into $PATH.
4) abe.sh has a bug setting up the symlink for the sysroot directory; it tried to create link builds/destdir/x86_64-unknown-linux-gnu/aarch64-linux-gnu/libc rather than builds/destdir/x86_64-unknown-linux-gnu/aarch64-none-linux-gnu//libc. Without fixing this, the final hello_world build step fails unless you hack that command to manually reference the sysroot.
This reply was marked as an answer to my original question. However, that's not the case; the investigation described here simply confirms that something odd is going on; the documented build steps yield the result I would expect, whereas the ARM-provided download isn't the same as the result of the documented build steps. Hopefully somebody from ARM that's involved in building the toolchain can determine where the discrepancy lies, and why.
View all questions in GNU Toolchain forum