I often translate the most computationally expensive routines in C++ using
IT++, then I call these routines from Matlab as mex files. The problem seems
to be that Matlab does not handle properly calls to routines from blas/acml
libraries. Both, Matlab and IT++ use these libraries, but they are stored in
buf = intrinsic_coded(i*nb_outputs,(i+1)*nb_outputs-1);
The line above is executed from a C++ program, however in a mex file this
gives an error:
Program received signal SIGSEGV, Segmentation fault.
0x00007fffe86528f1 in mkl_blas_def_dcopy ()
On my system, openSUSE 11.1, IT++ library is linked against ACML 4.3.0, while
mkl.so library comes from Matlab installation folder.
Any idea how should I fix this ?
Replying to myself: a possible solution would be the compilation of mex files
using static libraries.
The above problem exists only on an AMD Athlon64 machine running openSUSE. On
my laptop, with Atom Intel processor and the same OS, this problem does not
MATLAB carries its own ACML library in the binary directory. Different
versions of the library are incompatible (same object names). So I copied the
current ACML (MP) libraries into the MATLAB directory. I guess did some
LD_PRELOAD in the matlab starting script (libgomp?) to get all the libraries
loaded. You can check with "!ldd libacml_mp.so" from the MATLAB command line
which libraries and dependencies are seen from the matlab binary. At least for
me it works with ITPP/MEX and the current ACML.
On Windows Cygwin I have to redefine the ACML names like "#define dsytrf_
DSYTRF" with the correct Intel Fortran name mangling. Cygwin can produce
correct MEX-Files, when the Mingw32 GCC crosscompiler is used. I compiled the
mingw32-gcc myself (gcc 4-version).
I have found only two acml related libraries in
These are acmlcompat.so and acml.so. My guess is these two are already used by
some mex programs, found in Matlab software.
I have tried to create in the same folder two soft links to libacml_mp.so and
libacml_mv.so, but still I cannot use my own mex files.
For completeness I give below a small example:
void mexFunction(int n_output, mxArray output, int n_input, const mxArray
bin_out(i) = itpp::randu(1, 1);
itpp::vec v = bin_out(0).get_row(0);
When compiled with mex -litpp C_trial.cpp
mex -litpp C_trial.cpp
it generates a mex file which on openSUSE 11.2 with ACML libs determines a
An interesting issue is that when compiled for debugging
mex -g -litpp C_trial.cpp
it does not generate a crash.
However, my main application does generate a crash in both situations. Here is
the output I get when the crash occurs under gdb
470 bin = bin_out(j).get_row(s);//transition output (encoder)
0x00007fffe88468f1 in mkl_blas_def_dcopy ()
I used environment variables to tell MATLAB to load a different ACML:
On Windows this did not work. So I used a different ACML for MEX files. It
works only, if you set this environment variable:
I don't have the production machine at home, don't remember exactly what has
to be done. You have to play wit the library dependencies. In MATLAB, you have
to check with "!ldd library.so" if the library dependencies are correct.
Sorry, the forum was eating my underscores. It changed the letters to italic.
I checked the Installation at work. In ".matlab7rc.sh" I put this line at the
I had some trouble with the libgomp OpenMP-Library and Std-C++ Lib
dependencies. MATLAB is using own versions (old ones) that are incompatible to
my OpenSuse 11.1. I exchanged them a few times, don't remember which ones are
used at the moment. Just try. For me it works now with ITPP MEX-Files.
I have copied .matlab7rc.sh from /usr/local/matlab/bin to my home folder and
added the line Frank recommended. Now I am able to call my mex files from
I would also propose to gather this kind of useful information in HOWTO
articles in order to help others with the same kind of problems.