Gnuplot installation on Ubuntu 9.10
 

Happy new year, everyone:

I install gnuplot using:
sudo apt-get install gnuplot

When I begin to run the application, I get an error, saying:
gnuplot: /home/energeticsaerosol/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib/libwx_baseu-2.8.so.0)

At the same time, I get the same error after I install octave:
octave3.2: /home/energeticsaerosol/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib/octave-3.2.2/liboctinterp.so)

If anyone who has the similar experience, please give me a hand. Thank you.

Bin

Did you search for the answer yourself before asking?
I do not use Debian/Ubuntu, nor have I encountered this error yet, but googling with "ubuntu GLIBCXX_3.4.11 not found"
I very quickly found this on the forum:

http://www.cfd-online.com/Forums/openfoam-installation/69536-1-6-ubuntu-9-10-64bit-glibcxx_3-4-11-not-found.html

It even has "glibcxx_3.4.11 not found" in the URL. Did you already try this? If so, and it didn't work, why didn't you post your question there instead of starting a new thread?

Hi, Olesen,

I followed that post, and find the solution there, now I post it here so that anyone who will encounter the similar problem, just do as following:

cd /home/USER_NAME/OpenFOAM/ThirdParty-1.6.x/gcc-4.3.3/platforms/linux64/lib64

sudo mv libstdc++.so.6 libstdc++.so.6.orig
sudo ln -s /usr/lib/libstdc++.so.6.0.10 libstdc++.so.6

sudo mv libgcc_s.so.1 libgcc_s.so.1.orig
sudo ln -s /lib/libgcc_s.so.1
check the version of libstdc++.so.6.0.x before typing and put your USER_NAME in the path.

This solution is suggested by piprus.

Have a good new year.

Bin

Re-compiling gcc may be one better solution in my opinion.

Explanation
 

Under certain conditions, GCC creates a dynamic link dependency to its own internal glibc library (the one built at the time GCC was built). For example, the following code triggers the issue when compiled with -O2 (but not -O1).

#include <iostream>
int main(int, char*[]){ std::cout << std::endl; return 0}

If you remove the std::endl, then the dependency is not triggered. The fix is to tell the runtime linker where to find the library (libstdc++.so). You can do this in several ways. One way is to compile the search path right into the binary by adding the following flag to LDFLAGS: -Wl,-rpath,/Path/To/GCC/lib/

Another way is to add the search path when you execute the program:
LD_LIBRARY_PATH="/Path/To/GCC/lib/:$LD_LIBRARY_PATH" ./some_program

So to summarize, a runtime link dependency snuck into your build. The real bummer here is that it's not predictable -- you can't really know when GCC will insert this dependency. The same program compiled with different optimization flags yields a binary that no longer "runs". Some folks would call that a break in the optimization... but that's a debate for another day. The fix is band-aid the dependency by adding the runtime link path.

Hope this helps to explain what happened.