GLIBCXX_3.4.9 not found

Question

I have a problem concerning libstdc++.so.

I installed a new version of gcc and tried to compile C++ code. The compiling worked, but when I try to execute the binary (m5.opt is its name) I've got the following error:

build/ALPHA_SE/m5.opt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by build/ALPHA_SE/m5.opt).

Do I need to replace libstdc++.so? And if so, where can I download the version I want? On the GCC-website they say libstdc++ is a part of gcc now.

Details

GCC: I had gcc 4.1.2 before, but I downloaded gcc 4.2.4. From the untarred gcc-directory I executed ./configure; make; sudo make install`. When I tried to use gcc or g++ to compile, it's default version was still 4.1.2. To overcome this I replaced some links:

mv /usr/bin/gcc /usr/bin/gcc_bak
ln -s /usr/local/bin/gcc gcc
mv /usr/bin/g++ /usr/bin/g++_bak
ln -s /usr/local/bin/g++ g++

GLIBC(++) -- libstdc++:

/usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.8
/usr/local/lib/libstdc++.so -> libstdc++.so.6.0.9
/lib/libc.so.6 -> libc-2.5.so -> libc-2.5.so

Linux-version: uname -a gives:

Linux madmax 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 12:51:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Answer 1

The problem is that you built your new GCC incorrectly: on Linux you should use

./configure --prefix=/usr

The default installation prefix is /usr/local, which is why make install put gcc and g++ binaries into /usr/local/bin, etc.

What's happening to you now is that you compile and link using the new (symlinked) GCC 4.2.4, but at runtime your program binds to the old /usr/lib64/libstdc++.so.6 (version 6.0.8, instead of required 6.0.9). You can confirm that by running ldd build/ALPHA_SE/m5.opt: you should see that it uses /usr/lib64/libstdc++.so.6.

There are several fixes you could do.

env LD_LIBRARY_PATH=/usr/local/lib64 ldd build/ALPHA_SE/m5.opt

should show you that setting LD_LIBRARY_PATH is sufficient to redirect the binary to correct library, and

LD_LIBRARY_PATH=/usr/local/lib64 build/ALPHA_SE/m5.opt

should just run. You could "bake" this path into m5.opt binary by relinking it with -Wl,-rpath=/usr/local/lib64.

A more permanent solution is to fix the libraries the same way you fixed the binaries:

cd /usr/lib64 && mv libstdc++.so.6 libstdc++.so.6_bak &&
ln -s /usr/local/lib64/libstdc++.so.6 .

An even better solution is to reconfigure the new GCC with --prefix=/usr, and then make all install.

Answer 2

I know this is a very old question, but ...

It's not usually a good idea to replace the system compiler (i.e. the one in /usr) because the entire system will have been built with it and depend on it.

It's usually better to install the new compiler to a separate location and then see the libstdc++ FAQ How do I insure that the dynamically linked library will be found? and Finding Dynamic or Shared Libraries in the manual for how to ensure the correct libstdc++.so is found at runtime.

Answer 3

The other answers here should be fine, but the 'quick and easy' solution if you do happen to have gcc installed to /usr/local/ is to just add the new libs to the LD_LIBRARY_PATH

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64

You can also check the to see if you have the right versions of GLIBC installed using

strings /usr/lib/libstdc++.so.6 | grep GLIBC
strings /usr/local/lib64/libstdc++.so.18 | grep GLIBC

I got this last tip from another forum so credits due where credits due!