gcc 9.2 libstdc++ missing symbol versions

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*'|head

gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/lib64/libstdc++.so.6.0.28: file format elf64-littleaarch64

DYNAMIC SYMBOL TABLE:
00000000000b4568 l d .init 0000000000000000 .init
0000000000208728 l d .data 0000000000000000 .data
00000000001054c8 w DF .text 000000000000000c Base _ZNKSbIwSt11char_traitsIwESaIwEE8capacityEv
0000000000201650 w DO .data.rel.ro 0000000000000068 Base _ZTVNSt7__cxx1117moneypunct_bynameIwLb0EEE
0000000000101c80 w DF .text 0000000000000014 Base _ZNSsC1Ev
00000000001734c0 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-little

DYNAMIC SYMBOL TABLE:
00000000000f0890 w DF .text 000000000000000c GLIBCXX_3.4 _ZNKSbIwSt11char_traitsIwESaIwEE8capacityEv
00000000001d6840 w DO .data.rel.ro 0000000000000068 GLIBCXX_3.4.21 _ZTVNSt7__cxx1117moneypunct_bynameIwLb0EEE
00000000000ed620 w DF .text 0000000000000013 GLIBCXX_3.4 _ZNSsC1Ev
000000000015a0b0 w DF .text 0000000000000021 GLIBCXX_3.4.21 _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv
000000000011e160 w DF .text 0000000000000024 GLIBCXX_3.4 _ZNSt9money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEED0Ev
000000000018b4f8 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!

Parents
  • 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.

Reply
  • 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.

Children
No data
More questions in this forum