CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (http://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   Gnuplot installation on Ubuntu 9.10 (http://www.cfd-online.com/Forums/openfoam-post-processing/71458-gnuplot-installation-ubuntu-9-10-a.html)

zhoubinwx January 4, 2010 02:56

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

olesen January 4, 2010 06:05

Quote:

Originally Posted by zhoubinwx (Post 241400)
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)

...

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

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?

zhoubinwx January 4, 2010 22:15

Quote:

Originally Posted by olesen (Post 241422)
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

lin January 5, 2010 21:48

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

johnx January 19, 2010 21:06

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.


All times are GMT -4. The time now is 19:47.