How can I get GLIBCXX_3.4.15 in Ubuntu? I can't run some programs that I'm compiling.
When I do:
strings /usr/lib/libstdc++.so.6 | grep GLIBC
I get:
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
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.4
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
Thanks for any help!
Bug with GLIBCXX_3.4.14 You need to install a newer version of GCC. http://pkgs.org/download/libstdc++.so.6 goto:
http://geeksterminal.com/how-to-install-glib-glibc/1392/
and follow instructions.
I had the same problem before, and fixed that, the steps could be found on this Fixing error "GLIBCXX_3.4.15" on matlab
I have been avoiding this issue in the past by simply linking libstdc++ statically with this parameter sent to g++ when linking my executable:
-static-libstdc++
If linking in the library statically is an option this is probably the quickest work-around.
gcc version 4.8.1, the error seems like:
/root/bllvm/build/Release+Asserts/bin/llvm-tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /root/bllvm/build/Release+Asserts/bin/llvm-tblgen)
I found the libstdc++.so.6.0.18 at the place where I complied gcc 4.8.1
Then I do like this
cp ~/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.18 /usr/lib64/
rm /usr/lib64/libstdc++.so.6
ln -s libstdc++.so.6.0.18 libstdc++.so.6
problem solved.
I got same error. This is how it worked for me:
Worked perfectly!
I've had a similar issue, and I've resolved it by statically linking libstdc++ into the program I was compiling, like so:
$ LIBS=-lstdc++ ./configure ... etc.
instead of the usual
$ ./configure ... etc.
There might be problems with this solution to do with loading shared libraries at runtime, but I haven't looked into the issue deeply enough to comment.
Sometimes you don't control the target machine (e.g. your library needs to run on a locked-down enterprise system). In such a case you will need to recompile your code using the version of GCC that corresponds to their GLIBCXX version. In that case, you can do the following:
strings /usr/lib/libstdc++.so.6 | grep GLIBC ... Say the version is 3.4.19.[4.8.3, 4.9.0).I had the same problem because I changed the user from myself to someone else:
su
For some reason, after did the normal compiling I was not able to execute it (the same error message). Directly ssh to the other user account works.
For testing purposes:
On the original machine, find the library, copy to the same directory as the executable:
$ ldconfig -p | grep libstdc
libstdc++.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libstdc++.so.6 (libc6) => /usr/lib32/libstdc++.so.6
$ cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 .
Then copy this same library to the target machine, and run the executable:
LD_LIBRARY_PATH=. ./myexecutable
Note: command above is temporary; it is not a system-wide change.
I just used -static-libstdc++ while building. w/ that, I can run the a.out
g++ test.cpp -static-libstdc++
I was trying to get clang to work (which also requires 6.0.15), and while poking around I found it was installed at /usr/local/lib/libstdc++.so.6.0.15. It installed there when I installed graphite (an experimental gcc version).
If you need access to libraries at that location, then you’ll need to define LD_LIBRARY_PATH as:
export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/local/lib64:/usr/lib64
I was able to get clang to work after doing this. Hope that is helpful to someone.
Same thing with gcc version 4.8.1 (GCC) and libstdc++.so.6.0.18. Had to copy it here /usr/lib/x86_64-linux-gnu on my ubuntu box.
I encounter this problem when trying to use matlab eng to call m functions from c code.
which occurs with command mex -f .. ..
My solution:
strings /usr/lib/i386-<tab>/libstdc++.so.6 | grep GLIBC
I found it includes 3.4.15
so my system has the newest libs.
the problem comes from matlab itself, it calls its own libstdc++.so.6 from {MATLAB}/bin
so, just replace it with the updated system lib.
I've extracted them from an RPM (RPM for libstdc++) and then:
export LD_LIBRARY_PATH=.
To set the system to search for the libraries on the current directory. Then just executed my program. But in my case I've received a single executable that I needed, it wasn't a system wide change.
For this error, I copied the latest libstdc++.so.6.0.17 from other server, and removed the soft link and recreated it.
1. Copy the the libstdc++.so.6.0.15 or latest from other server to the affected system.
In my case SUSE linux 11 SP3 had latest.
2. rm libstdc++.so.6
3. ln -s libstdc++.so.6.0.17 libstdc++.so.6 (under /usr/lib64 directory).
nJoy
I had multiple versions of the gcc compiler installed and needed to use a more recent version than the default installation. Since I am not a system administrator for our Linux systems, I cannot just change /usr/lib or many of the other suggestions above. I was encountering this problem and eventually tracked it down to setting my path to the 32-bit library directory instead of the 64-bit library (lib64) directory. Since the libraries in the 32-bit directory were incompatible, the system defaulted to the older version which was out of date.
Using -L to the path I was referencing gave warnings about "skipping incompatible libstdc++.so when searching for -lstdc++". This was the hint that helped me finally resolve the problem.
I have just faced with similar issue building LLVM 3.7 version. first check whether you have installed the required library on your system:
$locate libstdc++.so.6.*
Then add the found location to your $LD_LIBRARY_PATH environment variable.
In my case LD_LIBRARY_PATH had /usr/lib64 first before /usr/local/lib64. (I was builing llvm 3.9).
The new gcc compiler that I installed to compile llvm 3.9 had libraries using newer GLIBCXX libraries under /usr/local/lib64 So I fixed LD_LIBRARY_PATH for the linker to see /usr/local/lib64 first.
That solved this problem.
Source: Stackoverflow.com