[c++] How to fix: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

So I'm now desperate in finding a fix for this. I'm compiling a shared library .so in Ubuntu 32 bit (Have tried doing it under Debian and Ubuntu 64 bit, but none worked either)

I keep getting: /usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.15' not found every time I try to load my plugin.

Here's how I'm getting this error:

1. Install latest Ubuntu 32 bit
2. sudo apt-get install build-essential
3. Compile & load my plugin (.so)

Here are some links which I found and tried, but none worked for me:

(My old question: I somehow got it fixed a few days after posting this question, but I can't remember how exactly I did it)

My Question

Another user with the same problem

And another

I see some people fixed it by moving libstdc++(i think) to some directory and then pointing or linking idk what to that directory, but that just puzzled me.

Anyone know a fix?

(Edit:) - Running: strings /usr/lib/libstdc++.so.6 | grep GLIBC in terminal gives me: strings '/usr/lib/libstdc++.so.6': No such file. Could that be the problem? And if so, how do I install this library?

(Edit2:) Anyone else know of a solution?

(Edit3) Still in need of a solution. is there a way to see on which distro a shared library was compiled on? I know I once compiled this same library a while ago, but can't remember!!

(Edit4) ldd my_lib_.so gives me:

    linux-gate.so.1 =>  (0xb77d7000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb76c1000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb76a4000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74fa000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb74ce000)
    /lib/ld-linux.so.2 (0xb77d8000)

ldd program_im_loading_so_into gives me:

    linux-gate.so.1 =>  (0xb77d8000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb77c0000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb77a5000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb76bb000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb768f000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7672000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74c9000)
    /lib/ld-linux.so.2 (0xb77d9000)

running strings /usr/lib/i386-linux-gnu/libstdc++.so.6 | grep GLIBCXX gives me:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH

and finally here's my gcc version:

`gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-1ubuntu1~12.04)`

this problem can be solved by installing the latest libstdc++.

$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get update
$ sudo apt-get install libstdc++6-7-dbg

Perhaps the answer to this question is of use here too: how to find libstdc++.so.6: that contain GLIBCXX_3.4.19 for RHEL 6?

curl -O http://ftp.de.debian.org/debian/pool/main/g/gcc-4.7/libstdc++6-4.7-dbg_4.7.2-5_i386.deb
ar -x libstdc++6-4.7-dbg_4.7.2-5_i386.deb && tar xvf data.tar.gz
mkdir backup
cp /usr/lib/libstdc++.so* backup/
cp ./usr/lib/i386-linux-gnu/debug/libstdc++.so.6.0.17 /usr/lib
ln -s libstdc++.so.6.0.17 libstdc++.so.6

This worked for me:

cp <path_to>/libstdc++.so.6 $PWD
./<executable>

This tidbit came from @kerin (comment provided above):

you might check out http://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas

From that link:

If you put the newer libstdc++.so in the same directory as the executable it will be found at run-time, problem solved.

The error I was getting mentioned that libstdc++.so.6 was coming from /usr/lib64/, but this is not the library I linked against! The message looked like:

<executing_binary>: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by <executing_binary>)

I did verify that LD_LIBRARY_PATH had the directory (and that it was the first path). For some reason at runtime it was still looking at /usr/lib64/libstdc++.so.6.

I took the advice from the article above and copied the libstdc++.so.6 from where I linked into the directory with my executable, ran from there, and it worked!

Actually, you need to update your repo first, then an upgrade of your Glibc can fix this issue.

I fixed this issue by installing: sudo apt-get install libstdc++6

In my case, I ran into this issue after installing MongoDB 3.0.1

mongo: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by mongo)

Link statically to libstdc++ with -static-libstdc++ gcc option.

Just install the latest version from nondefault repository:

$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get update
$ sudo apt-get install libstdc++6-4.7-dev

Up above, you mention having compiling your as part of your steps to reproduce, but then below you made an edit saying,

"is there a way to see on which distro a shared library was compiled on?"

Whether or not you compiled this on the same distro, and even a different version of the same distro is an important detail, especially for c++ applications.

Linking to c++ libraries, including libstdc++ can have mixed results, as far as I can tell. Here is a related question about recompiling with different versions of c++.

do we need to recompile libraries with c++11?

Basically, if you compiled against c++ on a different distro (and possibly different gcc version), this may be causing your trouble.

I think you have two options:

1. Your best bet - recompile your .so if you hadn't compiled it on your current system. If there is a problem with your runtime's system environment, it might even come out in the compile.
2. Bundle your other compiler's c++ libs along with your application. This may only be viable if it's the same distribution... But it's a useful trick if you rolled your own compiler. You will also have to set and export the LD_LIBRARY_PATH to the path containing your bundled stdc++ libs if you go that route.

If someone has the same issue as I had - make sure that you don't install from the Ubuntu 14.04 repo onto a 12.04 machine - it gives this same error. Reinstalling from the proper repository fixed the issue.