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!
> Seriously, if you're not compiling your entire system with this, you're better off with Linaro or crosstool-ng toolchain
... except that Linaro seems to have stopped providing stable builds of gcc, and now redirects to the ARM toolchain download site for stable ("official") builds:-( See https://www.linaro.org/downloads/. There are links to Linaro-provided "integration" builds of gcc, such as https://snapshots.linaro.org/gnu-toolchain/11.0-2021.03-1/, but there's a big "UNSTABLE" message on that download page, which makes me quite wary of using them for any production purpose, which I assume is the intent of that message.
But yes, I agree this original issue in this post does significantly reduce the reliability of the ARM toolchains.