MEX dynamic lib namespace collision?

I'm using a MEX interface to the numerical optimizer Ipopt. Ipopt links to Goto Blas and Netlib Lapack. According to ldd, ipopt.mexa64 depends on libgoto2 and not mwblas or mwlapack. However, a backtrace at lapack subroutine dpotrf_ shows that mwlapack is being used:

#0 0x00007fffeb99ed6d in dpotrf_ () from /soft/matlab2010b/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwlapack.so

#1 0x00007fffd92f0506 in Ipopt::IpLapackDpotrf (ndim=1, a=0x3e7aa90, lda=1, info=@0x7fffe8781ed0) at IpLapack.cpp:76

...

I suspect that this is caused by a namespace collision: ld is loading both libmwlapack and libgoto2, and the symbols are the same. The matlab blas/lapack APIs are different from Goto (8-byte integers versus 4-byte integers, respectively), so the namespace problem is critical.

Does anyone have advice on how to fix the problem?

Answer 1

[Kaustubha Govind]

This seems somewhat intractable to me, because the only way the libgoto2 symbols can be resolved correctly is by changing the version of LAPACK that MATLAB uses. However, doing this means that any calls that MATLAB makes into LAPACK (for libmwlapack.so) will now crash, because libgoto2 has a different interface.

This might require some other creative solution. For example, a less efficient technique would be to create an out-of-process server that your MEX function can call into for libgoto2 computations.