This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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