• State Not Answered
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 5302 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
  • +1

    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.

Reply
  • +1

    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.

Children