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.

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).

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.