Path: news.mathworks.com!not-for-mail
From: "Matthew" <mp_nospam@yahoo.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: running a c++ program using unix command
Date: Thu, 15 Jan 2009 02:13:02 +0000 (UTC)
Organization: Columbia
Lines: 153
Message-ID: <gkm63e$600$1@fred.mathworks.com>
References: <gj7286$dm1$1@fred.mathworks.com> <op.unrpuerwa5ziv5@uthamaa.dhcp.mathworks.com>
Reply-To: "Matthew" <mp_nospam@yahoo.com>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1231985582 6144 172.30.248.37 (15 Jan 2009 02:13:02 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Thu, 15 Jan 2009 02:13:02 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 839019
Xref: news.mathworks.com comp.soft-sys.matlab:511672


Ashish,

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.last@mathworks.com> wrote in message <op.unrpuerwa5ziv5@uthamaa.dhcp.mathworks.com>...
> 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.
> 
> 
> 
> 
>