Thread Subject: Problem runnin external C++ program from MATLAB

I am having a bit of an odd problem with an old (about 5
years) matlab program that compiles and runs some C++ code.
 Basically, the matlab program compiles some C++ source code
into an executable called "global" using the ! command:

!make -f makefile_matrix

It then runs the C code using ! and eval:

exec_string = sprintf('!./global C_%d.dat',NB_HEAD);
eval(exec_string)

(C_#.dat is just the name of an output file, passed to the C
program as an argument)

This was all working fine a few months ago... however now
when I try to run the program I get the following error when
it tries to execute "global":

./global:
/.automount/software/matlab73/sys/os/glnx86/libstdc++.so.6:
version `GLIBCXX_3.4.9' not found (required by ./global)

and the program doesn't run.

I'm not exactly sure why it's stopped working, though I may
have updated my version of gcc recently (I don't really
remember). What confuses me is that the C++ binary runs
fine if I just execute it from the command line in my shell.
 It's only when I try to run it from MATLAB using ! that I
get the error above. I suspect that there's some
compatibility issue between the version of gcc that I'm
using right now and the libstdc++.so.6 in the matlab
directory listed above. But I don't see why my C++ binary
is even looking in the matlab directory, when in principle
I'm running it outside of MATLAB using !.

Any explanations or suggestions?

Relevant info:
-MATLAB 7.30 (R2006b)
-gcc version 4.2.1
-OpenSUSE Linux 10.3

Any program compiled with GCC 4.2, requires GLIBC++ 3.4.9 to
run. The problem is that MATLAB secretly changes
LD_LIBRARY_PATH on startup to point to the MATLAB version of
GLIBC++, so that GLIBC++ 3.4.9 can no longer be found. The
solution is to modify matlab/bin/.matlab7rc.sh so that
"LDPATH_PREFIX" contains the path to the version of GLIB
installed with your compiler, then this is found before the
matlab-supplied library. For non-root users, simply copy the
said file to your home directory and edit it there. The line
you are looking for reads (originally):

LDPATH_PREFIX=''

but there are several of these. You need to edit the one in
the case statement for your architecture: you can identify
this by finding the set of lines:

#----------------------------------------------------------------------------
;;
glnx86)
#----------------------------------------------------------------------------

where instead of "glnx86", it reads out your architecture.
"glnx86" is Gnu/Linux x86; "glnxi64" is (I think) Gnu/Linux
Itanium 64-bit. As to the path you need to insert, you need
to find a path on your machine which holds the file
"libstdc++.so.6" (probably a symlink). On the Ubuntu Gutsy I
just installed, this is simply enough at "/usr/lib".



"Thomas Humphries" <thomash_no_spam@sfu.ca> wrote in message
<fn5oi2$59f$1@fred.mathworks.com>...
> I am having a bit of an odd problem with an old (about 5
> years) matlab program that compiles and runs some C++ code.
> Basically, the matlab program compiles some C++ source code
> into an executable called "global" using the ! command:
>
> !make -f makefile_matrix
>
> It then runs the C code using ! and eval:
>
> exec_string = sprintf('!./global C_%d.dat',NB_HEAD);
> eval(exec_string)
>
> (C_#.dat is just the name of an output file, passed to the C
> program as an argument)
>
> This was all working fine a few months ago... however now
> when I try to run the program I get the following error when
> it tries to execute "global":
>
> ./global:
> /.automount/software/matlab73/sys/os/glnx86/libstdc++.so.6:
> version `GLIBCXX_3.4.9' not found (required by ./global)
>
> and the program doesn't run.
>
> I'm not exactly sure why it's stopped working, though I may
> have updated my version of gcc recently (I don't really
> remember). What confuses me is that the C++ binary runs
> fine if I just execute it from the command line in my shell.
> It's only when I try to run it from MATLAB using ! that I
> get the error above. I suspect that there's some
> compatibility issue between the version of gcc that I'm
> using right now and the libstdc++.so.6 in the matlab
> directory listed above. But I don't see why my C++ binary
> is even looking in the matlab directory, when in principle
> I'm running it outside of MATLAB using !.
>
> Any explanations or suggestions?
>
> Relevant info:
> -MATLAB 7.30 (R2006b)
> -gcc version 4.2.1
> -OpenSUSE Linux 10.3

Any program compiled with GCC 4.2, requires GLIBC++ 3.4.9 to
run. The problem is that MATLAB secretly changes
LD_LIBRARY_PATH on startup to point to the MATLAB version of
GLIBC++, so that GLIBC++ 3.4.9 can no longer be found. The
solution is to modify matlab/bin/.matlab7rc.sh so that
"LDPATH_PREFIX" contains the path to the version of GLIB
installed with your compiler, then this is found before the
matlab-supplied library. For non-root users, simply copy the
said file to your home directory and edit it there. The line
you are looking for reads (originally):

LDPATH_PREFIX=''

but there are several of these. You need to edit the one in
the case statement for your architecture: you can identify
this by finding the set of lines:

#----------------------------------------------------------------------------
;;
glnx86)
#----------------------------------------------------------------------------

where instead of "glnx86", it reads out your architecture.
"glnx86" is Gnu/Linux x86; "glnxi64" is (I think) Gnu/Linux
Itanium 64-bit. As to the path you need to insert, you need
to find a path on your machine which holds the file
"libstdc++.so.6" (probably a symlink). On the Ubuntu Gutsy I
just installed, this is simply enough at "/usr/lib".



"Thomas Humphries" <thomash_no_spam@sfu.ca> wrote in message
<fn5oi2$59f$1@fred.mathworks.com>...
> I am having a bit of an odd problem with an old (about 5
> years) matlab program that compiles and runs some C++ code.
> Basically, the matlab program compiles some C++ source code
> into an executable called "global" using the ! command:
>
> !make -f makefile_matrix
>
> It then runs the C code using ! and eval:
>
> exec_string = sprintf('!./global C_%d.dat',NB_HEAD);
> eval(exec_string)
>
> (C_#.dat is just the name of an output file, passed to the C
> program as an argument)
>
> This was all working fine a few months ago... however now
> when I try to run the program I get the following error when
> it tries to execute "global":
>
> ./global:
> /.automount/software/matlab73/sys/os/glnx86/libstdc++.so.6:
> version `GLIBCXX_3.4.9' not found (required by ./global)
>
> and the program doesn't run.
>
> I'm not exactly sure why it's stopped working, though I may
> have updated my version of gcc recently (I don't really
> remember). What confuses me is that the C++ binary runs
> fine if I just execute it from the command line in my shell.
> It's only when I try to run it from MATLAB using ! that I
> get the error above. I suspect that there's some
> compatibility issue between the version of gcc that I'm
> using right now and the libstdc++.so.6 in the matlab
> directory listed above. But I don't see why my C++ binary
> is even looking in the matlab directory, when in principle
> I'm running it outside of MATLAB using !.
>
> Any explanations or suggestions?
>
> Relevant info:
> -MATLAB 7.30 (R2006b)
> -gcc version 4.2.1
> -OpenSUSE Linux 10.3

HI!

I am having a similar problem. I am compiling a Mex file which includes a larger FEM package. I don't compile it inside the matlab command line because I need to use the Makefile that comes with the package . I modified it to include the mex-libraries and headers (the modified part is appended).
If I compile it in debug mode everything is fine and calling the mex file from Matlab cmd line works.
If I compile it in optimized mode the compile process runs fine but when I call the mexfile from matlab I get the following error:

 ??? Invalid MEX-file '/home/raid2/sknauf/Software/deal.II/MEXPBC/mex_ex.mexa64':
/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found (required by /home/raid2/sknauf/Software/deal.II/MEXPBC/mex_ex.mexa64)


I tried the solution mentioned in the previous post and changed the LDPATH_PREFIX. The directories I put there then appear in the LD_LIBRARY_PATH in the beginning. However, Matlab seems still to try to use the older version in its own directory ".../sys/os/glnxa64/".

I run SuSELinux 10.3 on a glnxa64 architecture,
gcc4.2.0 and matlabR2007b.

Regards
Jan

The makefile I use is

target = $(basename $(shell echo mex_ex*.cc))
debug-mode = off
D = /home/raid2/sknauf/Software/deal.II/2008-04-15
clean-up-files = *gmv *gnuplot *gpl *eps *pov

include $D/common/Make.global_options

libs.g = $(lib-deal2-2d.g) \
     $(lib-lac.g) \
           $(lib-base.g)
libs.o = $(lib-deal2-2d.o) \
     $(lib-lac.o) \
           $(lib-base.o)

ifeq ($(debug-mode),on)
  libraries = $(target).g.$(OBJEXT) $(libs.g)
else
  libraries = $(target).$(OBJEXT) $(libs.o)
endif

$(target) : $(libraries)
  echo ============================ Linking $@
  $(CXX) -o $@$(EXEEXT) $^ $(LIBS) $(LDFLAGS)

  echo ============================ Running $<
  ./$(target)$(EXEEXT)


clean:
  -rm -f *.$(OBJEXT) *~ Makefile.dep $(target)$(EXEEXT) $(clean-up-files)


/%.g.$(OBJEXT) :
  echo ==============debug========= $(<F)
  $(CXX) $(CXXFLAGS.g) -c $< -o $@
/%.$(OBJEXT) :
  echo ==============optimized===== $(<F)
  $(CXX) $(CXXFLAGS.o) -c $< -o $@


PHONY: run clean


MATLAB = /nfs/mounts/allarch/Matlab-R2007b
MATLABHOME = /nfs/software/matlab
INCLUDE += -I$(MATLABHOME)/extern/include
#CXX flags:
CXXFLAGS.o += -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread
CXXFLAGS.g += -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread
CXXDEBUGFLAGS = -g
CXXOPTIMFLAGS = -O -DNDEBUG
#CXXLIBS += -Wl,-rpath-link,/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -lmx -lmex -lmat -lm
LIBS += -Wl,-rpath-link,/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -L/usr/lib64 -L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -L/nfs/mounts/allarch/Matlab-R2007b/sys/os/glnxa64/ -lmx -lmex -lmat -lm
arguments = -DMX_COMPAT_32
#Link flags:
LDFLAGS += -L/usr/lib64 -pthread -shared -Wl,--version-script,/nfs/mounts/allarch/Matlab-R2007b/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -lmx -lmex -lmat -lm -L/nfs/mounts/allarch/Matlab-R2007b/sys/os/glnxa64/
LDDEBUGFLAGS = -g
LDOPTIMFLAGS = -O
LDEXTENSION = .mexa64
EXEEXT = .mexa64

Makefile.dep: $(target).cc Makefile \
              $(shell echo $D/*/include/*/*.h)
  @echo ============================ Remaking $@
  @$D/common/scripts/make_dependencies $(INCLUDE) -B. $(target).cc \
    > $@ \
    || (rm -f $@ ; false)
  @if test -s $@ ; then : else rm $@ ; fi

#This file sets all the varaiables for the compilation of the FEM package.
include Makefile.dep

> Any program compiled with GCC 4.2, requires GLIBC++
> 3.4.9 to
> run. The problem is that MATLAB secretly changes
> LD_LIBRARY_PATH on startup to point to the MATLAB
> version of
> GLIBC++, so that GLIBC++ 3.4.9 can no longer be
> found. The
> solution is to modify matlab/bin/.matlab7rc.sh so
> that
> "LDPATH_PREFIX" contains the path to the version of
> GLIB
> installed with your compiler, then this is found
> before the
> matlab-supplied library. For non-root users, simply
> copy the
> said file to your home directory and edit it there.
> The line
> you are looking for reads (originally):
>
> LDPATH_PREFIX=''
>
> but there are several of these. You need to edit the
> one in
> the case statement for your architecture: you can
> identify
> this by finding the set of lines:
>
> #-----------------------------------------------------
> -----------------------
> ;;
> glnx86)
> #-----------------------------------------------------
> -----------------------
>
> where instead of "glnx86", it reads out your
> architecture.
> "glnx86" is Gnu/Linux x86; "glnxi64" is (I think)
> Gnu/Linux
> Itanium 64-bit. As to the path you need to insert,
> you need
> to find a path on your machine which holds the file
> "libstdc++.so.6" (probably a symlink). On the Ubuntu
> Gutsy I
> just installed, this is simply enough at "/usr/lib".
>
>
>
> "Thomas Humphries" <thomash_no_spam@sfu.ca> wrote in
> message
> <fn5oi2$59f$1@fred.mathworks.com>...
> > I am having a bit of an odd problem with an old
> (about 5
> > years) matlab program that compiles and runs some
> C++ code.
> > Basically, the matlab program compiles some C++
> source code
> > into an executable called "global" using the !
> command:
> >
> > !make -f makefile_matrix
> >
> > It then runs the C code using ! and eval:
> >
> > exec_string = sprintf('!./global
> C_%d.dat',NB_HEAD);
> > eval(exec_string)
> >
> > (C_#.dat is just the name of an output file, passed
> to the C
> > program as an argument)
> >
> > This was all working fine a few months ago...
> however now
> > when I try to run the program I get the following
> error when
> > it tries to execute "global":
> >
> > ./global:
> >
> /.automount/software/matlab73/sys/os/glnx86/libstdc++.
> so.6:
> > version `GLIBCXX_3.4.9' not found (required by
> ./global)
> >
> > and the program doesn't run.
> >
> > I'm not exactly sure why it's stopped working,
> though I may
> > have updated my version of gcc recently (I don't
> really
> > remember). What confuses me is that the C++ binary
> runs
> > fine if I just execute it from the command line in
> my shell.
> > It's only when I try to run it from MATLAB using !
> that I
> > get the error above. I suspect that there's some
> > compatibility issue between the version of gcc that
> I'm
> > using right now and the libstdc++.so.6 in the
> matlab
> > directory listed above. But I don't see why my C++
> binary
> > is even looking in the matlab directory, when in
> principle
> > I'm running it outside of MATLAB using !.
> >
> > Any explanations or suggestions?
> >
> > Relevant info:
> > -MATLAB 7.30 (R2006b)
> > -gcc version 4.2.1
> > -OpenSUSE Linux 10.3
>

Hello!

Has there been any defitive progress on this issue? I have
the same problem, and my solution was to remove all the
libstdc++ (and libgcc_s) stuff from <matalb>/sys/os/<arch>.
This forces loader to use the libraries present in the
system instead. However, now Matlab freezes up now and then
when I'm working with mex... :(

/Dag Lindbo, Sweden

HI!

After some useless playing around with the library paths I ended up with your solution, too.
I also have problems with Matlab freezing, but this is only in debug mode when I do step by step evaluation...
If I run the script without any breakpoints set it does not freeze.
I would still be interested in a real solution, however.

Jan

jr74 <jan_ruebel@yahoo.de> wrote in message
<2122122.1214238977943.JavaMail.jakarta@nitrogen.mathforum.org>...
> HI!
>
> After some useless playing around with the library paths I
ended up with your solution, too.
> I also have problems with Matlab freezing, but this is
only in debug mode when I do step by step evaluation...
> If I run the script without any breakpoints set it does
not freeze.
> I would still be interested in a real solution, however.
>
> Jan

Hello,

I'm not sure whether it really changes anything but it is
maybe softer, instead of deleting the mathworks libraries,
to modify the symbolic links, so that Matlab still goes into
its favorite folder but the files it uses are actually
libraries of the system. For instance what I did was (in
$matlab/sys/os/glnx86/):

$ sudo mv libgcc_s.so.1 libgcc_s.so.1.back
$ sudo ln -s /lib/libgcc_s.so.1 libgcc_s.so.1
$ sudo rm libstdc++.so.6 (this was already a symbolic link)
$ sudo ln -s /usr/lib/libstdc++.so.6.0.9 libstdc++.so.6

Seems to work so far.

Alex

I had the same problem when using g++-4.2 to compile a MEX
file that has a statically initialized global object.
Changing LDPATH_PREFIX as explained in a previous post did
not work. The problem went away when I installed gcc-4.1
and used it to compile the MEX file.


jr74 <jan_ruebel@yahoo.de> wrote in message
<2664339.1208944195760.JavaMail.jakarta@nitrogen.mathforum.o
rg>...
> HI!
>
> I am having a similar problem. I am compiling a Mex file
which includes a larger FEM package. I don't compile it
inside the matlab command line because I need to use the
Makefile that comes with the package . I modified it to
include the mex-libraries and headers (the modified part is
appended).
> If I compile it in debug mode everything is fine and
calling the mex file from Matlab cmd line works.
> If I compile it in optimized mode the compile process
runs fine but when I call the mexfile from matlab I get the
following error:
>
> ??? Invalid MEX-
file '/home/raid2/sknauf/Software/deal.II/MEXPBC/mex_ex.mexa
64':
> /nfs/mounts/allarch/Matlab-
R2007b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6:
version
> `GLIBCXX_3.4.9' not found (required
by /home/raid2/sknauf/Software/deal.II/MEXPBC/mex_ex.mexa64)
>
>
> I tried the solution mentioned in the previous post and
changed the LDPATH_PREFIX. The directories I put there then
appear in the LD_LIBRARY_PATH in the beginning. However,
Matlab seems still to try to use the older version in its
own directory ".../sys/os/glnxa64/".
>
> I run SuSELinux 10.3 on a glnxa64 architecture,
> gcc4.2.0 and matlabR2007b.
>
> Regards
> Jan
>
> The makefile I use is
>
> target = $(basename $(shell echo mex_ex*.cc))
> debug-mode = off
> D = /home/raid2/sknauf/Software/deal.II/2008-04-15
> clean-up-files = *gmv *gnuplot *gpl *eps *pov
>
> include $D/common/Make.global_options
>
> libs.g = $(lib-deal2-2d.g) \
> $(lib-lac.g) \
> $(lib-base.g)
> libs.o = $(lib-deal2-2d.o) \
> $(lib-lac.o) \
> $(lib-base.o)
>
> ifeq ($(debug-mode),on)
> libraries = $(target).g.$(OBJEXT) $(libs.g)
> else
> libraries = $(target).$(OBJEXT) $(libs.o)
> endif
>
> $(target) : $(libraries)
> echo ============================ Linking $@
> $(CXX) -o $@$(EXEEXT) $^ $(LIBS) $(LDFLAGS)
>
> echo ============================ Running $<
> ./$(target)$(EXEEXT)
>
>
> clean:
> -rm -f *.$(OBJEXT) *~ Makefile.dep $(target)$(EXEEXT)
$(clean-up-files)
>
>
> /%.g.$(OBJEXT) :
> echo ==============debug========= $(<F)
> $(CXX) $(CXXFLAGS.g) -c $< -o $@
> /%.$(OBJEXT) :
> echo ==============optimized===== $(<F)
> $(CXX) $(CXXFLAGS.o) -c $< -o $@
>
>
> PHONY: run clean
>
>
> MATLAB = /nfs/mounts/allarch/Matlab-R2007b
> MATLABHOME = /nfs/software/matlab
> INCLUDE += -I$(MATLABHOME)/extern/include
> #CXX flags:
> CXXFLAGS.o += -ansi -D_GNU_SOURCE -fPIC -fno-omit-
frame-pointer -pthread
> CXXFLAGS.g += -ansi -D_GNU_SOURCE -fPIC -fno-omit-
frame-pointer -pthread
> CXXDEBUGFLAGS = -g
> CXXOPTIMFLAGS = -O -DNDEBUG
> #CXXLIBS += -Wl,-rpath-
link,/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -
L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -lmx -lmex -
lmat -lm
> LIBS += -Wl,-rpath-
link,/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -
L/usr/lib64 -L/nfs/mounts/allarch/Matlab-
R2007b/bin/glnxa64 -L/nfs/mounts/allarch/Matlab-
R2007b/sys/os/glnxa64/ -lmx -lmex -lmat -lm
> arguments = -DMX_COMPAT_32
> #Link flags:
> LDFLAGS += -L/usr/lib64 -pthread -shared -Wl,--
version-script,/nfs/mounts/allarch/Matlab-
R2007b/extern/lib/glnxa64/mexFunction.map -Wl,--no-
undefined -L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -
lmx -lmex -lmat -lm -L/nfs/mounts/allarch/Matlab-
R2007b/sys/os/glnxa64/
> LDDEBUGFLAGS = -g
> LDOPTIMFLAGS = -O
> LDEXTENSION = .mexa64
> EXEEXT = .mexa64
>
> Makefile.dep: $(target).cc Makefile \
> $(shell echo $D/*/include/*/*.h)
> @echo ============================ Remaking $@
> @$D/common/scripts/make_dependencies $(INCLUDE) -B.
$(target).cc \
> > $@ \
> || (rm -f $@ ; false)
> @if test -s $@ ; then : else rm $@ ; fi
>
> #This file sets all the varaiables for the compilation of
the FEM package.
> include Makefile.dep
>
> > Any program compiled with GCC 4.2, requires GLIBC++
> > 3.4.9 to
> > run. The problem is that MATLAB secretly changes
> > LD_LIBRARY_PATH on startup to point to the MATLAB
> > version of
> > GLIBC++, so that GLIBC++ 3.4.9 can no longer be
> > found. The
> > solution is to modify matlab/bin/.matlab7rc.sh so
> > that
> > "LDPATH_PREFIX" contains the path to the version of
> > GLIB
> > installed with your compiler, then this is found
> > before the
> > matlab-supplied library. For non-root users, simply
> > copy the
> > said file to your home directory and edit it there.
> > The line
> > you are looking for reads (originally):
> >
> > LDPATH_PREFIX=''
> >
> > but there are several of these. You need to edit the
> > one in
> > the case statement for your architecture: you can
> > identify
> > this by finding the set of lines:
> >
> > #-----------------------------------------------------
> > -----------------------
> > ;;
> > glnx86)
> > #-----------------------------------------------------
> > -----------------------
> >
> > where instead of "glnx86", it reads out your
> > architecture.
> > "glnx86" is Gnu/Linux x86; "glnxi64" is (I think)
> > Gnu/Linux
> > Itanium 64-bit. As to the path you need to insert,
> > you need
> > to find a path on your machine which holds the file
> > "libstdc++.so.6" (probably a symlink). On the Ubuntu
> > Gutsy I
> > just installed, this is simply enough at "/usr/lib".
> >
> >
> >
> > "Thomas Humphries" <thomash_no_spam@sfu.ca> wrote in
> > message
> > <fn5oi2$59f$1@fred.mathworks.com>...
> > > I am having a bit of an odd problem with an old
> > (about 5
> > > years) matlab program that compiles and runs some
> > C++ code.
> > > Basically, the matlab program compiles some C++
> > source code
> > > into an executable called "global" using the !
> > command:
> > >
> > > !make -f makefile_matrix
> > >
> > > It then runs the C code using ! and eval:
> > >
> > > exec_string = sprintf('!./global
> > C_%d.dat',NB_HEAD);
> > > eval(exec_string)
> > >
> > > (C_#.dat is just the name of an output file, passed
> > to the C
> > > program as an argument)
> > >
> > > This was all working fine a few months ago...
> > however now
> > > when I try to run the program I get the following
> > error when
> > > it tries to execute "global":
> > >
> > > ./global:
> > >
> > /.automount/software/matlab73/sys/os/glnx86/libstdc++.
> > so.6:
> > > version `GLIBCXX_3.4.9' not found (required by
> > ./global)
> > >
> > > and the program doesn't run.
> > >
> > > I'm not exactly sure why it's stopped working,
> > though I may
> > > have updated my version of gcc recently (I don't
> > really
> > > remember). What confuses me is that the C++ binary
> > runs
> > > fine if I just execute it from the command line in
> > my shell.
> > > It's only when I try to run it from MATLAB using !
> > that I
> > > get the error above. I suspect that there's some
> > > compatibility issue between the version of gcc that
> > I'm
> > > using right now and the libstdc++.so.6 in the
> > matlab
> > > directory listed above. But I don't see why my C++
> > binary
> > > is even looking in the matlab directory, when in
> > principle
> > > I'm running it outside of MATLAB using !.
> > >
> > > Any explanations or suggestions?
> > >
> > > Relevant info:
> > > -MATLAB 7.30 (R2006b)
> > > -gcc version 4.2.1
> > > -OpenSUSE Linux 10.3
> >

I had the same problem when using g++-4.2 to compile a MEX
file that has a statically initialized global object.
Changing LDPATH_PREFIX as explained in a previous post did
not work. The problem went away when I installed gcc-4.1
and used it to compile the MEX file.


jr74 <jan_ruebel@yahoo.de> wrote in message
<2664339.1208944195760.JavaMail.jakarta@nitrogen.mathforum.o
rg>...
> HI!
>
> I am having a similar problem. I am compiling a Mex file
which includes a larger FEM package. I don't compile it
inside the matlab command line because I need to use the
Makefile that comes with the package . I modified it to
include the mex-libraries and headers (the modified part is
appended).
> If I compile it in debug mode everything is fine and
calling the mex file from Matlab cmd line works.
> If I compile it in optimized mode the compile process
runs fine but when I call the mexfile from matlab I get the
following error:
>
> ??? Invalid MEX-
file '/home/raid2/sknauf/Software/deal.II/MEXPBC/mex_ex.mexa
64':
> /nfs/mounts/allarch/Matlab-
R2007b/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6:
version
> `GLIBCXX_3.4.9' not found (required
by /home/raid2/sknauf/Software/deal.II/MEXPBC/mex_ex.mexa64)
>
>
> I tried the solution mentioned in the previous post and
changed the LDPATH_PREFIX. The directories I put there then
appear in the LD_LIBRARY_PATH in the beginning. However,
Matlab seems still to try to use the older version in its
own directory ".../sys/os/glnxa64/".
>
> I run SuSELinux 10.3 on a glnxa64 architecture,
> gcc4.2.0 and matlabR2007b.
>
> Regards
> Jan
>
> The makefile I use is
>
> target = $(basename $(shell echo mex_ex*.cc))
> debug-mode = off
> D = /home/raid2/sknauf/Software/deal.II/2008-04-15
> clean-up-files = *gmv *gnuplot *gpl *eps *pov
>
> include $D/common/Make.global_options
>
> libs.g = $(lib-deal2-2d.g) \
> $(lib-lac.g) \
> $(lib-base.g)
> libs.o = $(lib-deal2-2d.o) \
> $(lib-lac.o) \
> $(lib-base.o)
>
> ifeq ($(debug-mode),on)
> libraries = $(target).g.$(OBJEXT) $(libs.g)
> else
> libraries = $(target).$(OBJEXT) $(libs.o)
> endif
>
> $(target) : $(libraries)
> echo ============================ Linking $@
> $(CXX) -o $@$(EXEEXT) $^ $(LIBS) $(LDFLAGS)
>
> echo ============================ Running $<
> ./$(target)$(EXEEXT)
>
>
> clean:
> -rm -f *.$(OBJEXT) *~ Makefile.dep $(target)$(EXEEXT)
$(clean-up-files)
>
>
> /%.g.$(OBJEXT) :
> echo ==============debug========= $(<F)
> $(CXX) $(CXXFLAGS.g) -c $< -o $@
> /%.$(OBJEXT) :
> echo ==============optimized===== $(<F)
> $(CXX) $(CXXFLAGS.o) -c $< -o $@
>
>
> PHONY: run clean
>
>
> MATLAB = /nfs/mounts/allarch/Matlab-R2007b
> MATLABHOME = /nfs/software/matlab
> INCLUDE += -I$(MATLABHOME)/extern/include
> #CXX flags:
> CXXFLAGS.o += -ansi -D_GNU_SOURCE -fPIC -fno-omit-
frame-pointer -pthread
> CXXFLAGS.g += -ansi -D_GNU_SOURCE -fPIC -fno-omit-
frame-pointer -pthread
> CXXDEBUGFLAGS = -g
> CXXOPTIMFLAGS = -O -DNDEBUG
> #CXXLIBS += -Wl,-rpath-
link,/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -
L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -lmx -lmex -
lmat -lm
> LIBS += -Wl,-rpath-
link,/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -
L/usr/lib64 -L/nfs/mounts/allarch/Matlab-
R2007b/bin/glnxa64 -L/nfs/mounts/allarch/Matlab-
R2007b/sys/os/glnxa64/ -lmx -lmex -lmat -lm
> arguments = -DMX_COMPAT_32
> #Link flags:
> LDFLAGS += -L/usr/lib64 -pthread -shared -Wl,--
version-script,/nfs/mounts/allarch/Matlab-
R2007b/extern/lib/glnxa64/mexFunction.map -Wl,--no-
undefined -L/nfs/mounts/allarch/Matlab-R2007b/bin/glnxa64 -
lmx -lmex -lmat -lm -L/nfs/mounts/allarch/Matlab-
R2007b/sys/os/glnxa64/
> LDDEBUGFLAGS = -g
> LDOPTIMFLAGS = -O
> LDEXTENSION = .mexa64
> EXEEXT = .mexa64
>
> Makefile.dep: $(target).cc Makefile \
> $(shell echo $D/*/include/*/*.h)
> @echo ============================ Remaking $@
> @$D/common/scripts/make_dependencies $(INCLUDE) -B.
$(target).cc \
> > $@ \
> || (rm -f $@ ; false)
> @if test -s $@ ; then : else rm $@ ; fi
>
> #This file sets all the varaiables for the compilation of
the FEM package.
> include Makefile.dep
>
> > Any program compiled with GCC 4.2, requires GLIBC++
> > 3.4.9 to
> > run. The problem is that MATLAB secretly changes
> > LD_LIBRARY_PATH on startup to point to the MATLAB
> > version of
> > GLIBC++, so that GLIBC++ 3.4.9 can no longer be
> > found. The
> > solution is to modify matlab/bin/.matlab7rc.sh so
> > that
> > "LDPATH_PREFIX" contains the path to the version of
> > GLIB
> > installed with your compiler, then this is found
> > before the
> > matlab-supplied library. For non-root users, simply
> > copy the
> > said file to your home directory and edit it there.
> > The line
> > you are looking for reads (originally):
> >
> > LDPATH_PREFIX=''
> >
> > but there are several of these. You need to edit the
> > one in
> > the case statement for your architecture: you can
> > identify
> > this by finding the set of lines:
> >
> > #-----------------------------------------------------
> > -----------------------
> > ;;
> > glnx86)
> > #-----------------------------------------------------
> > -----------------------
> >
> > where instead of "glnx86", it reads out your
> > architecture.
> > "glnx86" is Gnu/Linux x86; "glnxi64" is (I think)
> > Gnu/Linux
> > Itanium 64-bit. As to the path you need to insert,
> > you need
> > to find a path on your machine which holds the file
> > "libstdc++.so.6" (probably a symlink). On the Ubuntu
> > Gutsy I
> > just installed, this is simply enough at "/usr/lib".
> >
> >
> >
> > "Thomas Humphries" <thomash_no_spam@sfu.ca> wrote in
> > message
> > <fn5oi2$59f$1@fred.mathworks.com>...
> > > I am having a bit of an odd problem with an old
> > (about 5
> > > years) matlab program that compiles and runs some
> > C++ code.
> > > Basically, the matlab program compiles some C++
> > source code
> > > into an executable called "global" using the !
> > command:
> > >
> > > !make -f makefile_matrix
> > >
> > > It then runs the C code using ! and eval:
> > >
> > > exec_string = sprintf('!./global
> > C_%d.dat',NB_HEAD);
> > > eval(exec_string)
> > >
> > > (C_#.dat is just the name of an output file, passed
> > to the C
> > > program as an argument)
> > >
> > > This was all working fine a few months ago...
> > however now
> > > when I try to run the program I get the following
> > error when
> > > it tries to execute "global":
> > >
> > > ./global:
> > >
> > /.automount/software/matlab73/sys/os/glnx86/libstdc++.
> > so.6:
> > > version `GLIBCXX_3.4.9' not found (required by
> > ./global)
> > >
> > > and the program doesn't run.
> > >
> > > I'm not exactly sure why it's stopped working,
> > though I may
> > > have updated my version of gcc recently (I don't
> > really
> > > remember). What confuses me is that the C++ binary
> > runs
> > > fine if I just execute it from the command line in
> > my shell.
> > > It's only when I try to run it from MATLAB using !
> > that I
> > > get the error above. I suspect that there's some
> > > compatibility issue between the version of gcc that
> > I'm
> > > using right now and the libstdc++.so.6 in the
> > matlab
> > > directory listed above. But I don't see why my C++
> > binary
> > > is even looking in the matlab directory, when in
> > principle
> > > I'm running it outside of MATLAB using !.
> > >
> > > Any explanations or suggestions?
> > >
> > > Relevant info:
> > > -MATLAB 7.30 (R2006b)
> > > -gcc version 4.2.1
> > > -OpenSUSE Linux 10.3
> >

I solved this by unsetting EV's when I spawn the shell.

E.g.:

>>!foo --help
foo: /usr/local/matlab2008b/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by foo)
>>!sh -c "unset LD_LIBRARY_PATH;foo --help"
foo [-h --help]
>>

I indeed encountered the same problem but have a (maybe) easier solution.

Matlab messes with the LD_LIBRARY_PATH, putting there common libraries precompiled by Matlab itself using a potentially older gcc version.

Solution: Compile from command-line instead of Matlab resolved all my problems:
MATLABDIR/bin/mex yprime.c

I have the same problem for one year now and I wonder if there are some news about it..
Modifying LD_LIBRARY_PATH in .matalb7rc.sh did not work for me neither.
Is there any way that matlab bins are linked to unix system libraries rather than to libraries incorporated into matlab ?
In advance Thank you,
Ronan

In my case, setting LDPATH_PREFIX or LD_PREFIX_PATH in .matlab7rc.sh did not work.
However, my system is an ubuntu and if I set the LD_PRELOAD environment variable before launching matlab, it works : ie, preload the three next system libraries :

setenv LD_PRELOAD '/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6.0.13:/lib/libz.so.1.2.3.3'

Thus the stdc++, gcc and z libraries provided in matlab are not loaded.
The advantage is that only a environment variable is set and that matlab libraries or config files are not affected.


"Ronan " <ronan.trepos@toulouse.inra.fr> wrote in message <i3boe8$q2p$1@fred.mathworks.com>...
> I have the same problem for one year now and I wonder if there are some news about it..
> Modifying LD_LIBRARY_PATH in .matalb7rc.sh did not work for me neither.
> Is there any way that matlab bins are linked to unix system libraries rather than to libraries incorporated into matlab ?
> In advance Thank you,
> Ronan

Compiling outside of matlab

and performing:

ldd ./source/Matlab/lib/GP_Loader/GP_Loader.mexa64
linux-vdso.so.1 => (0x00007fff8259b000)
libmx.so => not found
libmex.so => not found
libmat.so => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f21bb43a000)
libm.so.6 => /lib/libm.so.6 (0x00007f21bb1b7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f21baf9f000)
libc.so.6 => /lib/libc.so.6 (0x00007f21bac1c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f21bb98e000)

and looking specifically at

libstdc++.so.6 => /usr/lib/libstdc++.so.6

Then calling matlab like so at the cmd prompt:

LD_PRELOAD=/usr/lib/libstdc++.so.6 /opt/MatlabR2010a/bin/matlab

was the magic recipe for me on Ubuntu Server 10.10 x64

I am with the rest of the group. Changes to the shell scripts had no effect. Matlab needs better scripts... ones that are not so onerous and except LD_LIBRARY_PATH

I also tried compiling within matlab using mex. This met with the same nonfunctional result.

One other note from my post above. My GP_Loader dll loads my other plugin dlls and use of LD_LIBRARY_PATH works for GP_Loader to dynamically load my .so files.

LD_LIBRARY_PATH=/home/bdavis5/projects/NIH2009/branches/trunk/build/Linux-2.6.32-27-server/install/bin LD_PRELOAD=/usr/lib/libstdc++.so.6 /opt/MatlabR2010a/bin/matlab

I do this because matlab does not detach from the dll that contains the mexFunciton so I created a loader so that I can use it to detach from my dll's and recompile out from underneath matlab without having to reload all my data into memory. Something else Matlab folks need to fix.

Great, finally I have the solution to this bloody problem!! Thanks Brian! This one worked for me, too, whilst all other solutions stated above did not. From now on I use this command to start Matlab:

LD_PRELOAD=/usr/lib/libstdc++.so.6 /usr/local/matlabR2010a/bin/matlab

where " /usr/local/matlabR2010a" is the place where Matlab is installed. You get it by typing "matlabroot" in the Matlab prompt.

So thanks again, Brian!! You saved my day!

"Brian" wrote in message <ihkpt8$23q$1@fred.mathworks.com>...
> Compiling outside of matlab
>
> and performing:
>
> ldd ./source/Matlab/lib/GP_Loader/GP_Loader.mexa64
> linux-vdso.so.1 => (0x00007fff8259b000)
> libmx.so => not found
> libmex.so => not found
> libmat.so => not found
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f21bb43a000)
> libm.so.6 => /lib/libm.so.6 (0x00007f21bb1b7000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f21baf9f000)
> libc.so.6 => /lib/libc.so.6 (0x00007f21bac1c000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f21bb98e000)
>
> and looking specifically at
>
> libstdc++.so.6 => /usr/lib/libstdc++.so.6
>
> Then calling matlab like so at the cmd prompt:
>
> LD_PRELOAD=/usr/lib/libstdc++.so.6 /opt/MatlabR2010a/bin/matlab
>
> was the magic recipe for me on Ubuntu Server 10.10 x64
>
> I am with the rest of the group. Changes to the shell scripts had no effect. Matlab needs better scripts... ones that are not so onerous and except LD_LIBRARY_PATH
>
> I also tried compiling within matlab using mex. This met with the same nonfunctional result.

Hi,

I had problems using the LD_PRELOAD trick to start matlab (i.e.: LD_PRELOAD=/usr/lib/libstdc++.so.6 <matlab>/bin/matlab)
I then got the following error when started matlab:
sed: /usr/local/matlab74/sys/os/glnxa64/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/libstdc++.so.6)
... (more lines omitted) ...

for me it worked just
    removing <matlab>/sys/ox/glnxa64/libgcc_s.so.1
    and substituting the link <matlab>/sys/ox/glnxa64/libstdc++.so.6 by one pointing to /usr/lib/libstdc++.so.6

Gerard.

"Brian" wrote in message <ihkpt8$23q$1@fred.mathworks.com>...
> Compiling outside of matlab
>
> and performing:
>
> ldd ./source/Matlab/lib/GP_Loader/GP_Loader.mexa64
> linux-vdso.so.1 => (0x00007fff8259b000)
> libmx.so => not found
> libmex.so => not found
> libmat.so => not found
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f21bb43a000)
> libm.so.6 => /lib/libm.so.6 (0x00007f21bb1b7000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f21baf9f000)
> libc.so.6 => /lib/libc.so.6 (0x00007f21bac1c000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f21bb98e000)
>
> and looking specifically at
>
> libstdc++.so.6 => /usr/lib/libstdc++.so.6
>
> Then calling matlab like so at the cmd prompt:
>
> LD_PRELOAD=/usr/lib/libstdc++.so.6 /opt/MatlabR2010a/bin/matlab
>
> was the magic recipe for me on Ubuntu Server 10.10 x64
>
> I am with the rest of the group. Changes to the shell scripts had no effect. Matlab needs better scripts... ones that are not so onerous and except LD_LIBRARY_PATH
>
> I also tried compiling within matlab using mex. This met with the same nonfunctional result.

Hello !
Reason for posting:
1> Update to the solution suggested by Brian to use LD_PRELOAD to start MATLAB.
2> libstdc++.so.6 may not be always located in /usr/lib

MATLAB version concerned:
MATLAB R2011a and R2011b (64 bit)
OS: Ubuntu 11.04 (kernel:Linux ubuntu 2.6.38-11-generic) , (64 bit)
C++ compiler: gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)

Precise solution:
Start MATLAB with following command
LD_PRELOAD = "Dirlocation"/libstdc++.so.6 "DirForMATLAB_Shell"/matlab

For example:
libstdc++.so.6 located on "/usr/lib64/x86_64-linux-gnu/"
MATLAB is located on "/usr/local/MATLAB/R2011b/bin"

Start MATLAB by following command:
LD_PRELOAD=/usr/lib64/x86_64-linux-gnu/libstdc++.so.6 /usr/local/MATLAB/R2011b/bin/matlab

Further reading: https://help.ubuntu.com/community/MATLAB#MATLAB_R2011a

with regards,
YP
===
"Brian" wrote in message <ihkpt8$23q$1@fred.mathworks.com>...
> Compiling outside of matlab
>
> and performing:
>
> ldd ./source/Matlab/lib/GP_Loader/GP_Loader.mexa64
> linux-vdso.so.1 => (0x00007fff8259b000)
> libmx.so => not found
> libmex.so => not found
> libmat.so => not found
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f21bb43a000)
> libm.so.6 => /lib/libm.so.6 (0x00007f21bb1b7000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f21baf9f000)
> libc.so.6 => /lib/libc.so.6 (0x00007f21bac1c000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f21bb98e000)
>
> and looking specifically at
>
> libstdc++.so.6 => /usr/lib/libstdc++.so.6
>
> Then calling matlab like so at the cmd prompt:
>
> LD_PRELOAD=/usr/lib/libstdc++.so.6 /opt/MatlabR2010a/bin/matlab
>
> was the magic recipe for me on Ubuntu Server 10.10 x64
>
> I am with the rest of the group. Changes to the shell scripts had no effect. Matlab needs better scripts... ones that are not so onerous and except LD_LIBRARY_PATH
>
> I also tried compiling within matlab using mex. This met with the same nonfunctional result.