Path: news.mathworks.com!not-for-mail
From: "Ashish Uthama" <first.last@mathworks.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: running a c++ program using unix command
Date: Wed, 14 Jan 2009 17:24:04 -0500
Organization: TMW
Lines: 94
Message-ID: <op.unrpuerwa5ziv5@uthamaa.dhcp.mathworks.com>
References: <gj7286$dm1$1@fred.mathworks.com>
 <gkllvq$96u$1@fred.mathworks.com>
NNTP-Posting-Host: uthamaa.dhcp.mathworks.com
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
X-Trace: fred.mathworks.com 1231971844 10950 172.31.57.126 (14 Jan 2009 22:24:04 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 14 Jan 2009 22:24:04 +0000 (UTC)
User-Agent: Opera Mail/9.60 (Win32)
Xref: news.mathworks.com comp.soft-sys.matlab:511650


On Wed, 14 Jan 2009 16:38:02 -0500, Matthew <mp_nospam@yahoo.com> wrote:

> Hello,
>
> 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
>

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.