`GLIBCXX_3.4.11' not found, run system call from MATLAB that links to glibc different than what's in matlab bin path

I'm trying to circumvent using MEX to link to MATLAB and just call a binary using "!" as in:

>> !template_image_rigid -args ....
template_image_rigid: /opt/MatlabR2010a/sys/os/glnxa64/libstdc++.so.6: version    `GLIBCXX_3.4.11' not found (required by /usr/lib/libboost_program_options.so.1.40.0)
template_image_rigid: /opt/MatlabR2010a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /开发者_StackOverflowusr/lib/libdirac_encoder.so.0)

Is there a way to easily fix this dynamic link issue from within MATLAB? I know I can recompile the source with MATLAB and use a MEX call, but since it takes a while to run the solver I just want to run it as shell command and import text data later into MATLAB.

If it helps, the source & CMakeLists.txt can be found here: https://github.com/pkarasev3/nlmagick/tree/master/samples

---

Grr, community = fail.

Diagnoising: do !gnome-terminal from within matlab and look at "env":

env | grep Matlab

which gives

XKEYSYMDB=/opt/MatlabR2010a/X11/app-defaults/XKeysymDB
MATLABPATH=/opt/MatlabR2010a/toolbox/local
XAPPLRESDIR=/opt/MatlabR2010a/X11/app-defaults
LD_LIBRARY_PATH=/opt/MatlabR2010a/sys/os/glnxa64:/opt/MatlabR2010a/bin/glnxa64:/opt/MatlabR2010a/extern/lib/glnxa64:/opt/MatlabR2010a/runtime/glnxa64:/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/amd64/native_threads:/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/a  md64/server:/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/amd64
OSG_LD_LIBRARY_PATH=/opt/MatlabR2010a/sys/openscenegraph/lib/glnxa64
TOOLBOX=/opt/MatlabR2010a/toolbox
XFILESEARCHPATH=/opt/MatlabR2010a/sys/java/jre/glnxa64/jre/lib/locale/%L/%T/%N%S::/usr/dt/app-defaults/%L/Dt
MATLAB=/opt/MatlabR2010a

Ok so the LD_LIBRARY_PATH is bad.

Trick: write a poltergeist script and run it from gnome-terminal, Launch it from Matlab with:

!./hack.sh  RunStuffThatLinksElsewhere

where hack.sh is a script with something like:

#!/bin/bash
source ~/.bashrc
export LD_LIBRARY_PATH=''
gnome-terminal --command="${1}"

so an easy test is to try it with "eog", this hack gets around the link issue and lets you run it from within matlab...

---

Simpler:

 setenv('foo',num2str(some_value) )
 !LD_LIBRARY_PATH=""   &&   ./my_binary -f $foo
 disp('done with external program!')

---

I solved this problem by replacing the version of libstdc++.so.6 with a newer version from my system (I use ubuntu 12.04).

First find the system version of libstdc++.so.6.

From the command line type:

locate libstdc++.so.6

My system version of libstdc was

/usr/lib/i386-linux-gnu/libstdc++.so.6

Then replace the matlab libstdc version with a link to the system libstdc.

From the command line type (replace [....] with you settings):

cd [matlab_dir]/sys/os/glnx86 
mv libstdc++.so.6 libstdc++.so.6-OLD 
ln -s [your_system_version_of_libstdc] libstdc++.so.6

---

I recently ran into the same problem. My solution also uses a poltergeist script like other answers. The script is as follows (poltergeist.sh):

#!/bin/bash
export LD_LIBRARY_PATH=''
eval "$@"

It basically resets the library path and subsequently evaluates the call given by the arguments to the script. From within matlab I then call in this manner:

system([pwd,'/poltergeist.sh echo hello world!']);

The advantage to this approach is that you can dynamically modify the call command within matlab. As far as I know this is not possible using the bang syntax in the currently provided answers.