Mex file calling LAPACK on MacOS

The compile of a MEX file fails on MacOS (works on Linux and Windows). The lapack function used is dpotrf and the linking step fails with:

>> Undefined symbols for architecture x86_64: >> "_dpotrf_", referenced from:

On Linux the LAPACK functions need to be referenced with an underscore added: dpotrf_, while on Windows just dpotrf worked. Should "_dpotrf_" be used on Mac?

This is code I wrote and distribute. I do not have access to a Mac. A user emailed me that he could not compile the code with:

>> mex -llapack QUIC.C QUIC-mex.C -output QUIC.mexmaci64

Compile on Windows succeeds with:

mex -llapack QUIC.C QUIC-mex.C -output QUIC.mexw64

and on Linux with:

mex -llapack QUIC.C QUIC-mex.C -output QUIC.mexa64

The Matlab Mex documents do not mention Mac support. Maybe MacOs is not officially supported?

Thanks!

Answer 1

[James Tursa]

Don't add the leading underscore yourself ... the compiler will do that. For the trailing underscore you can use a macro. E.g., try putting this at the top of your code (expand to include whatever function symbols you need):

#if !defined(_WIN32) && !defined(_WIN64)
#define  dpotrf  dpotrf_
#endif

Alternatively, you can include the lapack.h or blas.h header file that ships with MATLAB, but that is not available for early versions of MATLAB, so the above is more robust.

[Matyas]

Thank you for your response. Yes, I already have defines taking care of the name: I use "dpotrf" on Windows and "dpotrf_" otherwise.

That means that I use "dpotrf_" on MacOs as well. I wonder: is that correct?

From your answer I gather that on MacOs one extra underscore is added (by the MEX compiler presumably) to the beginning of the name resulting in "_dpotrf_". Therefore the linker sees that name, even though that is not what is in the source.

I can guess two possiblities. First, "_dpotrf_" is not found because the name should be "_dpotrf", hence my question whether the trailing underscore is correct. Or second, "_dpotrf_" is not found, because the lapack library itself is not found.

On Linux and Windows -llapack is all you need to link with LAPACK. The MEX compiler seems to know by default where the LAPACK (which ships with Matlab) is to be found. Maybe this is broken on MacOs? Maybe a specific -Ldir argument is needed for the mex compiler?

I hoped to hear from someone who successfully compiled a MEX file on MacOs that calls any LAPACK functions and would share the compile command and naming convention used.

[James Tursa]

I don't have a Mac to test with myself, so can't answer specifically about the trailing underscore. I had assumed that it needed it. Try it both ways, and if you get the same error then it is probably not linking in the library as you suspect. One thing you can do just to get things working is copy the library to your working directory and then explicitly link it in there. That way you can at least discover exactly which name is used.