Join Log in
Score:1
Anh Tran avatar Ubuntu

libstdc++.so.6 is linking to the wrong version

vn flag
Anh Tran

In the past, my ignorance has led me to messing around with gcc/g++ version. As of current, I'm using Ubuntu 18.04 and running gcc --version gave me this:

gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

However, after some debugging, I realised that my libstdc++.so.6 is linking against the wrong version. I knew about this by running ls -l /usr/lib/x86_64-linux-gnu/libstdc++.so.6, which gave me:

lrwxrwxrwx 1 root root 19 May 19  2020 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.28

Checking against the ABI, apparently it came from gcc 9.3.0, which I do remember installing at one point. This has caused me some weird bugs when programming C++.

Now, I would like to link libstdc++.so.6 back to gcc 8 but I'm not sure what's the less idiotic way to do this. Should I try removing GCC 9 and reinstall GCC 8?

Running locate libstdc++.so.6 gave me this:

/opt/nvidia/nsight-systems/2020.3.2/host-linux-x64/libstdc++.so.6
/opt/nvidia/nsight-systems/2020.3.2/target-linux-armv8/host-linux-armv8/libstdc++.so.6
/snap/core18/1988/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/snap/core18/1988/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
/snap/core18/1988/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25-gdb.py
/snap/core18/2066/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/snap/core18/2066/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25
/snap/core18/2066/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25-gdb.py
/usr/lib/i386-linux-gnu/libstdc++.so.6
/usr/lib/i386-linux-gnu/libstdc++.so.6.0.28
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
/usr/share/gdb/auto-load/usr/lib/i386-linux-gnu/libstdc++.so.6.0.28-gdb.py
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28-gdb.py
656
0 + 6
apt
gcc
hr flag
steeldriver
AFAIK, `libstdc++6.0.xx` is not related to a particular gcc version - it's part of a standalone `libstdc++6` package. What actual problem(s) are you trying to solve?
0
Reply
Anh Tran avatar
vn flag
Anh Tran
@steeldriver It seems like my binaries is linking to the wrong shared libary (libstdc++.so.6) which caused the program to crash (seg fault)
0
Reply
cn flag
Ray
What if you tried removing the package that `libstdc++6.0.28` belongs to and then installing the one that you want? That is, ignore gcc 8 or 9 issue.
0
Reply
Anh Tran avatar
vn flag
Anh Tran
What should I do to figure out which packages depends on libstdc++6.0.28?
0
Reply
N0rbert avatar
zw flag
N0rbert
Please add the output of `dpkg -S libstdc++.so.6` and `apt-cache policy $(dpkg -S libstdc++.so.6 | awk -F: '{print $1}' | sort -u)` to the question.
1
Reply
hr flag
steeldriver
I really think you should do some more debugging on the cause(s) of the segfaults before going down this rabbit hole - AFAIK libstdc++ always provides *backward* ABI compatibility ex. on my 18.04 box (where I have libstdc++6.0.29.so) it provides CXX ABIs from 1.3.1 (gcc 4.?) to 1.3.13 (gcc 11.1), as indicated by the output of `nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.29 | grep CXXABI`
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.