• State Not Answered
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 6398 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

swarren

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
  • 0 in reply to swarren

    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.

Reply
  • 0 in reply to swarren

    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.

Children
No data