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.
Thanks!
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.