Linking mex with Lapack

Hi,

I have a small test code (mex function, 'test_lapack.cpp') that solves a linear system. To do this it calls another function written as a separate C++ file ('solve.cpp'). The C++ file calls the dgesv_ function of the lapack library. On my mac with MATLAB R2015a, I compile these as:

mex test_lapack.cpp solve.cpp -llapack

and it compiles and I can use the resulting function in MATLAB. When I do a similar thing on linux (centOS) with MATLAB R2013a:

mex test_lapack.cpp solve.cpp -lliblapack.so.3.2.1

the code still compiles. But when I call the resulting function from MATLAB, MATLAB crashes giving the following error:

INTEL MKL ERROR: parameter 2 was incorrect on entry to DGESV .

I am not sure why the Intel MKL version of lapack is being used even though I explicitly linked it to the non-intel library and the compiler is g++ (not the intel one).

I would appreciate any help in resolving this.

Thanks

Answer 1

[Walter Roberson]

-lliblapack.so.3.2.1 is not a specific link against liblapack.so.3.2.1 . Instead, it adds liblapack.so.3.2.1 to the list of libraries to link against to resolve symbols. There is still a library order, and earlier libraries in the order may have resolved the symbol. Especially since you are using a .so instead of requesting a static library link.

You probably need to change your LD_LIBRARY_PATH; see http://stackoverflow.com/questions/2726993/g-how-to-specify-preference-of-library-path

[Raunak Borker]

Thanks for the response.

I agree that it is very likely that some other library is resolving the symbols before it gets to the intended one. I tried setting the LD_LIBRARY_PATH, but couldn't get it working.

In case some other library is indeed resolving it, should just compiling it as

mex test_lapack.cpp solve.cpp

work? It gives me an error saying 'dgesv' was not defined.

Thanks

[Walter Roberson]

I am not up on how the version numbering works in Linux linking. My memory from a number of years ago on a Unix system is that the 3.2 might be recorded as the required major and minor version of liblapack but that the full exact name might not be associated. If that old method still holds true than any other liblapack.so on the LD_LIBRARY_PATH that meets the 3.2 or later requirement might be considered acceptable.

When you link with .so, you need to provide the library names and a search through is done to determine which libraries satisfies which symbols. But the .so executable code is not bound into the executable: it just builds the list saying which library to fetch the symbol from. And unless you use a -rpath, it is not the even an exact library path that is included, just the name of the library. Then at execution time, the first library with the matching name that meets the version requirements is pulled out and used to try to satisfy the symbols.

Provided you are not executing as root or with an suid / sguid executable, the work around would be to execute with an LD_LIBRARY_PATH or possibly DYLD_LIBRARY_PATH in which you took care to have your desired liblapack before the standard library locations. That might involve manipulating the LD_LIBRARY_PATH environment variable in MATLAB before you first call the function.

[Raunak Borker]

Thanks a lot Walter!

Your answer helped me get to these pages: http://www.mathworks.com/matlabcentral/newsreader/view_thread/253412 https://github.com/kyamagu/mexopencv/issues/45

So it seems like setting the LD_PRELOAD environment variable as

export LD_PRELOAD=/usr/lib64/liblapack.so.3:$LD_PRELOAD

puts this library at the top of the search list. And the code compiles, links and executes correctly.

I would appreciate any input on this workaround (is it the ideal thing to do or is just a hack that works?)

[Raunak Borker]

So it's not ideal to use LD_PRELOAD. Or atleast the way I am using it. Although my code runs with this fix, MATLAB seg faults for example while doing a least-squares fit using the basic fitting tool in plot.

[Walter Roberson]

Does not sound quite appropriate: http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick

I would think it more likely that the approach would be closer to

old_ld = getenv('LD_LIBRARY_PATH');
setenv('LD_LIBRARY_PATH', ['/usr/lib64/liblapack.so.3:', old_ld])