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!
I see that gcc-arm-8.2-2018.08-x86_64-aarch64-linux-gnu.tar.xz also has this problem, but the more recent gcc-arm-10.2-2020.11-x86_64-aarch64-none-linux-gnu.tar.xz does not, so I guess this was considered a bug and was fixed? I'm still curious what the implications are for the gcc 9.2 toolchain, since we have reason to use that rather than gcc 10.
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.
I don't know the answer, writing here merely to let you know I encountered the same problem. ARM official toolchain does not have versioned symbols in libstdc++. It even led me to weird crash after cross-compilation by two different compilers, the second of which had proper versioning.
I think this was done to increase portability, allowing resulting shared objects and binaries to be linked to any provided libstdc++. However, symbol versioning was introduced for a reason, and after seeing this and wasting 2 days debugging the incompatibilities caused I won't recommend official toolchain anymore. Seriously, if you're not compiling your entire system with this, you're better off with Linaro or crosstool-ng toolchain.
> 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.