I'm using a third party shared library (libsw_api.so) on Solaris, which when I try to load, produces the following error:
fatal: relocation error: file libsw_api.so:
symbol _ZNKSt9bad_alloc4whatEv: referenced symbol not found
The program exited with error code 1
When I run ldd on libsw_api.so, all references seem to be fulfilled, specifically the C++ standard library which points to libstdc++.so.6.0.3:
glispa02(fostopr)$ ldd libsw_api.so
...
libstdc++.so.6 => /usr/sfw/lib/libstdc++.so.6
...
glispa02(fostopr)$ ls -l /usr/sfw/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Jun 21 2010 /usr/sfw/lib/libstdc++.so.6 -> libstdc++.so.6.0.3
However that library does not export _ZNKSt9bad_alloc4whatEv,
glispa02(fostopr)$ nm /usr/sfw/lib/libstdc++.so.6 | grep bad_alloc
[7592] | 752340| 64|FUNC |GLOB |0 |2653 |_ZNSt9bad_allocD0Ev
[7324] | 752284| 56|FUNC |GLOB |0 |2652 |_ZNSt9bad_allocD1Ev
[8077] | 752228| 56|FUNC |GLOB |0 |2651 |_ZNSt9bad_allocD2Ev
[7519] | 356736| 76|FUNC |GLOB |0 |473 |_ZSt17__throw_bad_allocv
[7341] | 983588| 12|OBJT |WEAK |0 |3842 |_ZTISt9bad_alloc
[6569] | 777008| 13|OBJT |WEAK |0 |3317 |_ZTSSt9bad_alloc
[7299] | 983568| 20|OBJT |WEAK |0 |3841 |_ZTVSt9bad_alloc
What could be the problem? Wrong version? I'm not really good with C++ on Unix so I'ld appreciate any help.
Could this SPARC32PLUS vs. SPARC mismatch be the cause of the problem?
glispa02(fostopr)$ file libsw_api.so
libsw_api.so: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped
glispa02(fostopr)$ file /usr/sfw/lib/libstdc++.so.6.0.3
/usr/sfw/lib/libstdc++.so.6.0.3: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped, no debugging information available
My system:
glispa02(fostopr)$ cat /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009
glispa02(fostopr)$ uname -a
SunOS glispa02 5.10 Generic_141444-09 sun4u sparc SUNW,SPARC-Enterprise
Hi I'm also upgrading these files, I noticed that I should be using the libstdc++.so.6.0.9 file that comes with the distribution rather than the one in /usr/sfw/lib/
If you use pvs on the libstdc++.so.6 file, it will give you a bunch of entries matching: GLIBCXX, if you don't have an entry matching GLIBCXX_3.4.9, then the symbol bad_alloc::what is not in that library i.e. the library is older than the dependent object libsw_api.so
If this is the case then you probably need a newer version of libstdc++ - it would come with a newer version of g++
I encounter the same issue.
The cause is we export the wrong LD_LIBRARY_PATH
So that our shared library link to the original gcc's library (3.3) instead of our compiler (gcc 4.4).
Fix the linker problem should solve the issue
Related
For example, take the following minimal example:
#include <cstdio>
#include <stdexcept>
int main(int argc, char* argv[]){
#ifdef __GLIBCPP__
std::printf("GLIBCPP: %d\n",__GLIBCPP__);
#endif
#ifdef __GLIBCXX__
std::printf("GLIBCXX: %d\n",__GLIBCXX__);
#endif
throw std::runtime_error("Were are libstdc++.so.6 debug symbols?");
return 0;
}
When running it inside my gdb, it does not show the debug symbols for libstdc++.so.6:
$ g++ -o testmain test.cpp -ggdb --std=c++98 && gdb ./testmain
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
...
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./testmain...
(gdb) r
Starting program: /home/user/Downloads/testmain
GLIBCXX: 20200408
terminate called after throwing an instance of 'std::runtime_error'
what(): Were are libstdc++.so.6 debug symbols?
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt f
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0, 0, 0, 0, 0, 0, 0, 0, 29295, 0, 0, 0, 0, 0, 0, 0}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007ffff7be1859 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = ... <stderr>}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007ffff7e67951 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#3 0x00007ffff7e7347c in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#4 0x00007ffff7e734e7 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#5 0x00007ffff7e73799 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#6 0x000055555555524a in main (argc=1, argv=0x7fffffffdef8) at test.cpp:11
No locals.
(gdb)
It just shows No symbol table info available for the libstdc++.so.6 frames.
How can I show the symbols for the libstdc++.so.6?
Searching on this list https://packages.ubuntu.com/search?keywords=libstdc%2B%2B6, I already tried installing the following packages, but none of them fixed the problem:
libgcc-10-dev:amd64 <none> 10.2.0-5ubuntu1~20.0
libstdc++-10-dev:amd64 <none> 10.2.0-5ubuntu1~20.0
libstdc++6-10-dbg:amd64 <none> 10.2.0-5ubuntu1~20.0
libc6-amd64-cross:all <none> 2.31-0ubuntu7cross
linux-libc-dev-amd64-cross:all <none> 5.4.0-21.25cross
libc6-dev-amd64-cross:all <none> 2.31-0ubuntu7cross
libstdc++6-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libgcc-10-dev-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libstdc++-10-dev-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libstdc++6-10-dbg-amd64-cross:all <none> 10.2.0-5ubuntu1~20.04cross
libx32stdc++6-10-dbg:amd64 <none> 10.2.0-5ubuntu1~20.0
Related questions:
How do you find what version of libstdc++ library is installed on your linux machine?
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
Update 1
$ dpkg --list | grep libstdc++6
ii libstdc++6:amd64 10.2.0-5ubuntu1~20.04 amd64 GNU Standard C++ Library v3
ii libstdc++6-10-dbg-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (debug build) (amd64)
ii libstdc++6-7-dbg:amd64 7.5.0-6ubuntu2 amd64 GNU Standard C++ Library v3 (debug build)
ii libstdc++6-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (amd64)
Update 2
$ dpkg --list | grep libstdc++6
ii libstdc++6:amd64 10.2.0-5ubuntu1~20.04 amd64 GNU Standard C++ Library v3
ii libstdc++6-10-dbg:amd64 10.2.0-5ubuntu1~20.04 amd64 GNU Standard C++ Library v3 (debug build)
ii libstdc++6-10-dbg-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (debug build) (amd64)
ii libstdc++6-amd64-cross 10.2.0-5ubuntu1~20.04cross1 all GNU Standard C++ Library v3 (amd64)
Background Story:
Days ago, I was also curious about the same question as yours. But that's on CentOS.
What can I do differently after I install those missing debug info packages for gdb?
You can check the question to see what I learnt during searching, I solve your question with those prior knowledge.
In short, for the same thing, in CentOS the difficulties come down to installing the debug info packages. Because the gdb in CentOS tells what exact version of some debug info files you need to install and it gives the full command.
debuginfo-install glibc-2.17-307.el7.1.x86_64 libgcc-4.8.5-44.el7.x86_64 libstdc++-4.8.5-44.el7.x86_64
But this command just can't work and you need to manually add some package sources to install that .
However, as soon as you succeed installing the debug info packages, everything else is set up nicely, even the source files! You can s step into e.g. abort() and list around the source code!
In Ubuntu:
You have to find the exact version of your libstdc++.so.xxx and install the corresponding debug info files.
No libarary(e.g. libstdc++) source files will be installed and set up after install the corresponding debug info files packages. But you can manually do it with set substitute-path.
Answer Part:
I made my gdb work under Ubuntu 18.04.5 LTS. I think that may applies to yours too.
I assume you know this https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html .
So firstly I ldd my.a.out.
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fbfa6f84000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbfa697b000)
...
In my Ubuntu, reading debug symbol for libc.so.6 is successful. So I want to check both .so files' .gnu_debuglink section.
libc.so.6 is a link to libc-2.27.so
so I read the above section with readelf -x.gnu_debuglink libc-2.27.so and gives me:
Hex dump of section '.gnu_debuglink':
0x00000000 6c696263 2d322e32 372e736f 00000000 libc-2.27.so....
0x00000010 32e033a0 2.3.
This means its debug info file's name is libc-2.27.so, which exists in /usr/lib/debug/lib/x86_64-linux-gnu directory.
Now check libstdc++.so.6, which is a link to libstdc++.so.6.0.25 in my machine.
readelf -x.gnu_debuglink libstdc++.so.6.0.25 gives:
Hex dump of section '.gnu_debuglink':
0x00000000 31313961 34346139 39373538 31313436 119a44a997581146
0x00000010 32306338 65396438 65323433 64373039 20c8e9d8e243d709
0x00000020 34663737 66362e64 65627567 00000000 4f77f6.debug....
0x00000030 30573da0 0W=.
This 119a44a99758114620c8e9d8e243d7094f77f6.debug is a build-id debug file.
Learnt from your question and comments below, I do dpkg --list | grep libstdc++ and shows
ii libstdc++-7-dev:amd64 7.5.0-3ubuntu1~18.04 amd64 GNU Standard C++ Library v3 (development files)
ii libstdc++-8-dev:amd64 8.4.0-1ubuntu1~18.04 amd64 GNU Standard C++ Library v3 (development files)
ii libstdc++6:amd64 8.4.0-1ubuntu1~18.04 amd64 GNU Standard C++ Library v3
ii libstdc++6:i386 8.4.0-1ubuntu1~18.04 i386 GNU Standard C++ Library v3
So I sudo apt install libstdc++6-8-dbg.
Then I used dpgk-query -L libstdc++6-8-dbg to see what files are installed with this packages.
tianhe#tianhe-windy:/lib/x86_64-linux-gnu$ dpkg -L libstdc++6-8-dbg
/.
/usr
/usr/lib
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/f2
/usr/lib/debug/.build-id/f2/119a44a99758114620c8e9d8e243d7094f77f6.debug
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/debug
/usr/lib/x86_64-linux-gnu/debug/libstdc++.a
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6.0.25
/usr/lib/x86_64-linux-gnu/debug/libstdc++fs.a
/usr/share
/usr/share/doc
/usr/share/gdb
/usr/share/gdb/auto-load
/usr/share/gdb/auto-load/usr
/usr/share/gdb/auto-load/usr/lib
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/debug
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6.0.25-gdb.py
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so
/usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6
/usr/share/doc/libstdc++6-8-dbg
And I think I got the debug files when I saw this line:
/usr/lib/debug/.build-id/f2/119a44a99758114620c8e9d8e243d7094f77f6.debug.
Then I open gdb again and it works. I can now s step into string s = "hello";.
So try check what I describe above see if they match.
I followed these instructions https://www.hiroom2.com/ubuntu-2004-dbgsym-en/.
Adding the debug symbols repo:
#!/bin/sh -e
U=http://ddebs.ubuntu.com
C=$(lsb_release -cs)
cat <<EOF | sudo tee /etc/apt/sources.list.d/ddebs.list
deb ${U} ${C} main restricted universe multiverse
#deb ${U} ${C}-security main restricted universe multiverse
deb ${U} ${C}-updates main restricted universe multiverse
deb ${U} ${C}-proposed main restricted universe multiverse
EOF
wget -O - http://ddebs.ubuntu.com/dbgsym-release-key.asc | \
sudo apt-key add -
sudo apt update -y
Then install symbols for libstdc++6
sudo apt-get install libstdc++6-dbgsym
In addtion to #Rick's answer.
In ubuntu 20.04+, you need to install libstdc++6-dbgsym, and before this you need to add debug symbol repo to apt.
To get the source code, you should run apt source libstdc++6, then run ./debian/rules patch as described in debian/README.source.
(Personally I feel installing debug info and source code in ubuntu is much more complex than centOS. I suggest you to use centOS if you just want to have a look into libstdc++'s source code.
I have a windows 10 computer with atom version 1.52.0 and g++ (MinGW.org GCC Build-2) 9.2.0. I can run c++ programs in Atom with the gpp-compiler, but I don't like how the program output is in a new window rather than at the bottom of the Atom window. I'm trying to set up c++ with the script package, but when I run the program with the script package I get the following error.
g++: error: /mnt/c/Users/user/Documents/USACO/2015-2016/December/Silver/test.cpp: No such file or directory
g++: fatal error: no input files
compilation terminated.
I can run java programs with the script package btw. screenshot
A bit late to reply. But for those to come here from Google, on the script package page, it clearly says:
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
| Grammer | File Based | Selection Based | Required Package | Required in PATH | Notes |
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
| C++ | Yes | Yes | | xcrun clang++/g++ | Available only on macOS and Linux. Run with -std=c++14. |
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
Available only on macOS and Linux. Run with -std=c++14.
So, it seems it's not available for Windows. Instead, you can use another package called gpp-compiler:
https://atom.io/packages/gpp-compiler
It works fine on windows:
You'll need to install MinGW and add it to your PATH.
I'm trying to use std::future::wait_for(std::chrono::duration) in my application (in fact, I don't want to wait at all which makes this more frustrating, as you'll see), but in using anything from std::chrono, I am unable to run the application after cross-compiling it for my BeagleBone Black:
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.19' not found
Until I add the following lines to my code, this project compiles and runs great with an older version of GLIBCXX, but just to be able to check if a future's value is ready without blocking, I suddenly need all these newer libraries:
if (myFuture.wait_for(std::chrono::seconds(0)) == std::future_status::ready)
return true;
The BeagleBone Black comes with GLIBCXX_3.4.17 from GCC 4.6.3 - I've checked the C++ headers on the system, and as I suspected, all the functionality I need from the chrono library is there. So why does it ask for version 3.4.19?
I tried updating and upgrading Debian with sudo apt-get upgrade in the hopes that the newer libraries would be added. This had no effect. Besides, I would really like to be able to run on the stock image.
So I tried statically linking libstdc++ with -static-libstdc++ added to my LD flags. Now I'm apparently missing GLIBC-2.7 which can't be fixed in the same way with -static-libgcc
I'm out of ideas.
I was able to compile with a previous version of the function that required 3.4.19 by following steps in another answer.
Firstly, I checked what was needed from 3.4.19:
$ objdump -T myapp | grep "GLIBCXX_3.4.19"
00000000 DF *UND* 00000000 GLIBCXX_3.4.19 _ZNSt6chrono3_V212system_clock3nowEv
Then I searched for the same symbol in the library I have
$ objdump -T /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep "_ZNSt6chrono3_V212system_clock3nowEv"
But this returned nothing. On a hunch, I tried finding just 'chrono' instead
$ objdump -T /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 | grep "chrono"
00080828 g DF .text 0000002a GLIBCXX_3.4.11 _ZNSt6chrono12system_clock3nowEv
0008ae38 g DO .rodata 00000001 GLIBCXX_3.4.11 _ZNSt6chrono12system_clock12is_monotonicE
Bingo. While it's not an exact match, it looked good enough for me. I added an assembly directive to my source file to update the linkage for the requested symbol.
__asm__(".symver _ZNSt6chrono3_V212system_clock3nowEv,_ZNSt6chrono12system_clock3nowEv#GLIBCXX_3.4.11");
While it now compiles and runs, I am unable to say for sure that this substitution works as I have other hurdles to get around however I think I'd be safe in saying it's a solution.
It works the ".symver" change, but it will break your std::chrono timers and dates if you compile it with >= GCC 4.8, because std::chrono ABI had changes.
It will run with systems like Ubuntu 12.04 (GCC 4.6.3) but date & time will not be showed correctly.
I have a mex function which uses OpenCV that I'm trying to use. The compilation seems to work, but when I try and call the function within MATLAB I get this error:
Invalid MEX-file '/path/to/project/mexfunction.mexa64': libopencv_legacy.so.2.4: cannot open shared object file: No such file or directory
My OpenCV 2.4.5 install is located at /nwdata/username/ (I compiled myself from scratch using the OpenCV recommended settings from their documentation). I compile with mex using this function:
function cvmex(mexfile)
OCV_INC_DIR='/nwdata/username/include/opencv';·
OCV2_INC_DIR='/nwdata/username/include';·
OCV_LIB_DIR ='/nwdata/username/lib';·
mex(mexfile,'-g','-v',['-I',OCV2_INC_DIR],['-I',OCV_INC_DIR],['-L',OCV_LIB_DIR],'DUSE_DOUBLE',...
'-lopencv_legacy','-lopencv_imgproc','-lopencv_core','-lopencv_contrib','-lopencv_ml',...
'-lopencv_objdetect','-lopencv_calib3d','-lopencv_flann','-lopencv_features2d',...
'-lopencv_video','-lopencv_gpu');
end
When I compile, I get no errors. I then checked to see what the dependencies of the library are using ldd mexfunction.mexa64. Here is the relevant line:
libopencv_legacy.so.2.4 => /nwdata/username/lib/libopencv_legacy.so.2.4 (0x00002ad6a2123000)
Ok, so that seems alright. That file definitely exists:
[username#machine:/nwdata/username/lib]
$ ls -l libopencv_legacy*
lrwxrwxrwx 1 username REDACTED 25 Jul 15 15:07 libopencv_legacy.so -> libopencv_legacy.so.2.4.5
lrwxrwxrwx 1 username REDACTED 25 Jul 15 15:07 libopencv_legacy.so.2.4 -> libopencv_legacy.so.2.4.5
-rwxr-xr-x 1 username REDACTED 1303944 Jun 17 15:37 libopencv_legacy.so.2.4.5
[username#machine:/nwdata/username/lib]
$ file libopencv_legacy.so*
libopencv_legacy.so: symbolic link to `libopencv_legacy.so.2.4.5'
libopencv_legacy.so.2.4: symbolic link to `libopencv_legacy.so.2.4.5'
libopencv_legacy.so.2.4.5: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Running on Linux:
Linux machine#redacted 2.6.43.8-1.fc15.x86_64 #1 SMP Mon Jun 4 20:33:44 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
MATLAB R2011b, and g++ 4.6.3.
This seems odd. Any ideas? This machine is part of a cluster, so I don't have root access or anything.
I encountered a similar problem some days ago. This problem only happens when you using the matlab remotely on a cluster. Editing the LD_LIBRARY_FILE in Matlab is useless, and I don't know why. I solved the problem by defining the LD_LIBRARY_PATH in .bashrc (or .bash_profile).
I had a very similar problem and solved it by adding a soft link to the missing library in the Matlab binaries directory, where all the other libs were located, in my case:
sudo ln -s /users/marc/lib/libName.so /opt/matlab/MATLAB_R2014b_Linux_x86-64/bin/glnxa64/libName.so
solved the problem.
I compiled 2 different binaries on the same GNU/Linux server using g++ version 4.2.3.
The first one uses:
GLIBC_2.0
GLIBC_2.2
GLIBC_2.1
GLIBCXX_3.4
GLIBC_2.1.3
The second one uses:
GLIBC_2.0
GLIBC_2.2
GLIBC_2.1
GLIBCXX_3.4.9
GLIBCXX_3.4
GLIBC_2.1.3
Why the second binary uses GLIBCXX_3.4.9 that is only available on libstdc++.so.6.0.9 and not in libstdc++.so.6.0.8
What is the new feature generated by g++ that require an ABI break and force the system to have GLIBCXX_3.4.9?
Is there a way to disable this new feature to not require GLIBCXX_3.4.9?
To find out which of the listed GLIBCXX_3.4.9 symbol(s) your binary actually depends on, do this:
readelf -s ./a.out | grep 'GLIBCXX_3\.4\.9' | c++filt
Once you know which symbols to look for, you can trace back to the object which needs them:
nm -A *.o | grep _ZN<whatever>
Finally, to tie this back to source, you can do:
objdump -dS foo.o
and see which code is referencing the 3.4.9 symbol(s).
Since you asked for it, here are symbols having at least ABI version 3.4.9:
GLIBCXX_3.4.9 {
_ZNSt6__norm15_List_node_base4hook*;
_ZNSt6__norm15_List_node_base4swap*;
_ZNSt6__norm15_List_node_base6unhookEv;
_ZNSt6__norm15_List_node_base7reverseEv;
_ZNSt6__norm15_List_node_base8transfer*;
_ZNSo9_M_insertI[^g]*;
_ZNSt13basic_ostreamIwSt11char_traitsIwEE9_M_insertI[^g]*;
_ZNSi10_M_extractI[^g]*;
_ZNSt13basic_istreamIwSt11char_traitsIwEE10_M_extractI[^g]*;
_ZSt21__copy_streambufs_eofI[cw]St11char_traitsI[cw]EE[il]PSt15basic_streambuf*;
_ZSt16__ostream_insert*;
_ZN11__gnu_debug19_Safe_sequence_base12_M_get_mutexEv;
_ZN11__gnu_debug19_Safe_iterator_base16_M_attach_singleEPNS_19_Safe_sequence_baseEb;
_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv;
_ZN11__gnu_debug19_Safe_iterator_base12_M_get_mutexEv;
_ZNKSt9bad_alloc4whatEv;
_ZNKSt8bad_cast4whatEv;
_ZNKSt10bad_typeid4whatEv;
_ZNKSt13bad_exception4whatEv;
} GLIBCXX_3.4.8;
Run the file libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt through c++filt, grepping for GLIBCXX_3.4.9 to make sense of those names (they look like wildcards only). I didn't do it because those names become quite long and nested. Later versions mostly include c++1x stuff. See the file libstdc++-v3/config/abi/pre/gnu.ver for the above. Read here about the VERSION linker script command.
Well the first question is how did you generate the above list.
One would assume that the compiler is deterministic and thus link binaries in the same way.
I assume I got marked down for not answering the question directly but a comment would be nice. But I still think you have not provided the correct information and it would be nice to see the output of the command that shows your problem.
Assuming you used ldd:
You would get an output that looked like this:
lib<X>.so.<ver> => /usr/lib/lib<X>.so.<verM> (<Addr>)
But this is not the end of the story.
Trying doing an ls on the file it may be a symbolic link
> ls /usr/lilb/lib<X>.so.<verM>
lrwxrwxrwx 1 root root <Date> /usr/lib/lib<X>.so.<verM> -> lib<X>.so.<verM>.<verm>.<verp>