running a c++ program using unix command
John finn
I am trying to run an executable (compiled c++ program) from within matlab using either of unix, system or ! and i keep getting this error
"matlabR2008a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found"
but running the same executable directly in the terminal in linux, works perfectly fine. Is there something different about the way matlab makes system calls to linux?
specs of my setup are below:
linux Mandriva 2008
x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GNU/Linux
matlab version 7.6.0.324 (R2008a)
thanks
john
Ashish Uthama
Using 'ldd' on this file from within MATLAB (using '!') and outside MATLAB
would give a hint.
MATLAB updates LD_LIBRARY_PATH which is causing the executable to
dynamically link against MATLAB's libstdc++ (which it doest seem to like).
You might try resetting LD_LIBRARY_PATH in the same line that you shell
out.
Or, equivalently, create a wrapper shell script which sets up the paths as
required and have MATLAB call it instead.
John finn
that was exactly the problem its fixed by running the program from a shell script adding the following line before calling the executable.
export LD_LIBRARY_PATH=/usr/lib64;
thanks for that
"Ashish Uthama" <first...@mathworks.com> wrote in message <op.umxsy...@uthamaa.dhcp.mathworks.com>...
Matthew
I have the same problem. I've tried the suggestions described here and on another thread that discusses it, but none of them have worked. NB 'mexatexit.cpp' compiles and runs for me, but I need to use the STL classes.
My file, 'matreader.mexglx', compiles fine except for this warning;
Warning: You are using gcc version "4.2.4". The earliest gcc version supported
with mex is "4.0.0". The latest version tested for use with mex is "4.2.0".
When I try to run it I get this:
>> matreader("test")
??? Invalid MEX-file '/home/matt/Projects/SaveData/matreader.mexglx':
/home/matt/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found (required by
/home/matt/Projects/SaveData/matreader.mexglx).
So I went into <matlabroot>/sys/glnx86, where I found libstdc++.so.6, which in my case is a soft link to libstdc++.so.6.0.8 in the same directory.
Then I went and found my version of libstdc++.so.6 in /usr/lib, as others have done. There, it's a soft link to libstdc++.so.6.0.9 --a different version. But when I changed the soft link in sys/glnx86 to point to this version, I got this error message when I tried to restart Matlab:
/home/matt/bin/glnx86/MATLAB: /home/matt/bin/glnx86/../../sys/os/glnx86/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /home/matt/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6)
(I am also getting a 'locking assertion' error but that seems Java-related.) Finally when I run ldd from the shell, I get the following:
linux-gate.so.1 => (0xb7fc6000)
libmx.so => not found
libmex.so => not found
libmat.so => not found
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7f88000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e95000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e8a000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e72000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d22000)
/lib/ld-linux.so.2 (0xb7fc7000)
This has me pretty confused--so apparently it is finding libstdc++.so.6 in /usr/lib?! I don't understand that. NB I also altered LDPATH_PREFIX in /bin/scripts/matlab7rc.sh to equal '/usr/bin', to no effect.
Please help, thank you!
Matlab 2007b, Dell Inspiron 640m, Ubuntu 8.04
Matt
"John finn" <brain...@gmail.com> wrote in message <gj7286$dm1$1...@fred.mathworks.com>...
Ashish Uthama
I would suggest not altering the links by hand in your system directories
(I have been burned).
And dont make the MATLAB lib's point to your system libs, as the message
indicated your system libs are newer than what MATLAB has been built and
tested for.
The OP's issue was the executable needing the system libraries and NOT the
one's with MATLAB. He was able to solve this by changing his
LD_LIBRARY_PATH to have his system libs first in the path.
Your issue appears to be the other way around, the MEX files needs
MATLAB's lib version and NOT the system's version. From **within MATLAB**,
use the ldd command to see what the MEX file links against. Then updated
LD_LIBRARY_PATH using
setenv/getenv in MALTAB or
!setenv ...; ldd <mex file>
to ensure that it links against MATLAB libs first. I think the version in
your MATLAB install path would support STL's. But if it so turns out that
your STL use needs a newer version of GLIBC than what MATLAB
supports....you might be out of luck.
Key points:
ldd looks at LD_LIBRARY path to resolve .so's
MATLAB changes this env value, hence ldd from a shell and from within
MATLAB might show different linkage.
Matthew
Thanks very much for your suggestions. Unfortunately I still haven't figured out how to make it work yet. Running ldd from within Matlab (didn't know you could do that) did indeed produce different results, namely:
>>!ldd matreader.mexglx
./matreader.mexglx: /home/matt/sys/os/glnx86/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./matreader.mexglx)
linux-gate.so.1 => (0xb7f49000)
libmx.so => /home/matt/bin/glnx86/libmx.so (0xb7ee1000)
libmex.so => /home/matt/bin/glnx86/libmex.so (0xb7ed1000)
libmat.so => /home/matt/bin/glnx86/libmat.so (0xb7eb1000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e79000)
libstdc++.so.6 => /home/matt/sys/os/glnx86/libstdc++.so.6 (0xb7d9c000)
libgcc_s.so.1 => /home/matt/sys/os/glnx86/libgcc_s.so.1 (0xb7d91000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d78000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c29000)
libut.so => /home/matt/bin/glnx86/../../bin/glnx86/libut.so (0xb7b32000)
libicudata.so.36 => /home/matt/bin/glnx86/../../bin/glnx86/libicudata.so.36 (0xb7b30000)
libicuuc.so.36 => /home/matt/bin/glnx86/../../bin/glnx86/libicuuc.so.36 (0xb7a14000)
libicui18n.so.36 => /home/matt/bin/glnx86/../../bin/glnx86/libicui18n.so.36 (0xb78e5000)
libicuio.so.36 => /home/matt/bin/glnx86/../../bin/glnx86/libicuio.so.36 (0xb78da000)
libz.so.1 => /home/matt/bin/glnx86/../../bin/glnx86/libz.so.1 (0xb78c6000)
libmwservices.so => /home/matt/bin/glnx86/../../bin/glnx86/libmwservices.so (0xb7782000)
libmwmpath.so => /home/matt/bin/glnx86/../../bin/glnx86/libmwmpath.so (0xb7750000)
libmwm_dispatcher.so => /home/matt/bin/glnx86/../../bin/glnx86/libmwm_dispatcher.so (0xb76fa000)
libhdf5.so.0 => /home/matt/bin/glnx86/../../bin/glnx86/libhdf5.so.0 (0xb75ca000)
/lib/ld-linux.so.2 (0xb7f4a000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb75c1000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb75bd000)
libxerces-c.so.27 => /home/matt/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libxerces-c.so.27 (0xb71f5000)
libmwmathutil.so => /home/matt/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libmwmathutil.so (0xb717e000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb714e000)
libboost_filesystem-gcc-mt-1_33_1.so.1.33.1 => /home/matt/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_filesystem-gcc-mt-1_33_1.so.1.33.1 (0xb713e000)
libmwdatasvcs.so => /home/matt/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libmwdatasvcs.so (0xb7127000)
libmwxmlcore.so => /home/matt/bin/glnx86/../../bin/glnx86/../../bin/glnx86/../../bin/glnx86/libmwxmlcore.so (0xb70b4000)
Sorry that's a lot but crucially,
libstdc++.so.6 => /home/matt/sys/os/glnx86/libstdc++.so.6 (0xb7d9c000)
And indeed when I modify LD_LIBRARY_PATH as follows:
>> oldpath = getenv('LD_LIBRARY_PATH');
>> setenv('LD_LIBRARY_PATH', ['/usr/lib:' oldpath])
the dependency changes accordingly, namely
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d90000)
Nothing else changes, in particular not
libgcc_s.so.1 => /home/matt/sys/os/glnx86/libgcc_s.so.1 (0xb7d85000)
which might be relevant? (Shot in the dark.) In any case, when I recompile I get the same warning, and when I try to run the program again I get the same error. I might as well not have changed anything. NB when I restart Matlab, LD_LIBTARY_PATH is reset, maybe that means Matlab isn't 'seeing' the setenv change? Anyway, I am definitely stumped at this point, please let me know if you have any more ideas!
Best,
Matt
I just don't get it--if m
"Ashish Uthama" <first...@mathworks.com> wrote in message <op.unrpu...@uthamaa.dhcp.mathworks.com>...
Ashish Uthama
Are you facing this issue with all MEX files you create? Does this project
source code have any specific GLIBC version dependencies?
Without any changes (in link targets or env variables), you should be able
to compile a simple MEX file (a printf ) and run it. This would link
against the libraries in MATLAB install path. If not, please post what you
see (warnings/error message, outputs of LDD from within MATLAB).
Any changes you do to LD_LIBRARY_PATH from within MATLAB (using SETENV)
are not retained between MATLAB sessions. For that matter, it is not
retained in a *nix shell either. You would have to explicitly set it each
time if you so choose (use startup.m/matlabrc).
Matthew
mexatexit.cpp compiles and runs for me just fine. The headers I use which aren't in mexatexit are <fstream> and <iostream>. And mexcpp.cpp, which includes <fstream> DOESN'T run in the same manner--compiles with warning, then gives the same error message. I doubt this is related but I can only compile these programs when I copy them to a directory which isn't a subdirectory of Matlab; otherwise I get a 'permission denied, can't create matreader.o'--despite chmod 777. Like I say probably irrelevant but I thought I'd mention it.
Best,
Matt
"Ashish Uthama" <first...@mathworks.com> wrote in message <op.unvdj...@uthamaa.dhcp.mathworks.com>...
free seek
LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 matlab
I had the same problem and change the environment variable LD_LIBRARY_PATH did not do anything for me. Using the command
setenv('LD_PRELOAD','/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6');
from matlab also did not do anything. Does anybody have an explanation for this?
Hyung-Sung Jung
I have the similar problem in R2009a. There was no problem in R2008a.
I have encounter the following problem to build rapid accelerator simulation execution file.
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwservices.so: undefined reference to `std::bad_alloc::what() const@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libut.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<bool>(bool)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwsl_solver_rtw.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<unsigned long>(unsigned long)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libut.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long>(long)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwm_interpreter.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::basic_istream<char, std::char_traits<char> >::_M_extract<unsigned long>(unsigned long&)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwm_interpreter.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<void const*>(void const*)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwsl_solver_rtw.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwsl_solver_rtw.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)@GLIBCXX_3.4.9'
/home/junghs/bin/MATLAB_2009a/bin/glnxa64/libmwm_interpreter.so: undefined reference to `std::basic_istream<char, std::char_traits<char> >& std::basic_istream<char, std::char_traits<char> >::_M_extract<double>(double&)@GLIBCXX_3.4.9'
I have two kinds of linux platform, Ubuntu & centOS.
To solve the above problem in Ubuntu OS, I have just copied 'libstdc++.so.6.0.9' (which is provided by matlab) to /usr/lib directory and have made soft link to 'libstdc++.so.6'. After this operation, I have cleared the above problem.
But I cannot clear this issue in centOS platform. Please give me your precious comments.
Thanks.
Michael Hamilton
I had this same error when trying to use a C++ program with mex:
>> mexcpp(3,4)
??? Invalid MEX-file '/home/hamilton/projects/slita/matlab_mex/mexcpp.mexa64':
/matlab2007b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required
by /home/hamilton/projects/slita/matlab_mex/mexcpp.mexa64).
Note that I was using the stock, mexcpp.cpp C++ example including in the distribution of Matlab, which I have copied to a local directory. This error occurs when I compile using the mex command at the Unix command line, after configuration with mex --setup for gcc.
After turning on verbose in the mex command and manually compiling with various options, I narrowed it down to the -O option. Without the -O option in the compile command, the program works in matlab. With the -O option in the compile command, the GLIBCXX error mentioned above shows up....
So, I edited my ~/.matlab/R2007b/mexopts.sh line in the glnxa64 section:
CXXOPTIMFLAGS='-O -DNDEBUG'
change to:
CXXOPTIMFLAGS='-DNDEBUG'
The -O in the LDOPTIMFLAGS doesn't matter (I assume because -O when linking doesn't really do much, it's the compiling, right?)
Why this happens I don't know. Perhaps I need to install some "optimized" version of the libraries? I haven't seen this particular solution documented for this error, so, I thought I'd add it for posterity. Hope it helps someone. I've been set back by this for months.
Background info:
My OS: (from cat /etc/lsb-release)
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.10
DISTRIB_CODENAME=intrepid
DISTRIB_DESCRIPTION="Ubuntu 8.10"
uname -a:
Linux HOSTNAME 2.6.27-14-generic #1 SMP Wed Apr 15 19:29:46 UTC 2009 x86_64 GNU/Linux
Matlab version: 7.5.0.338 (R2007b)
Best Regards,
Mike