mex compilation failure after most recent macOS update

The CMake Mex compilation fails for C Mex file with the following error after the most recent macOS/xcode update:

Undefined symbols for architecture arm64:

"_mexCreateMexFunction", referenced from:

<initial-undefines>

"_mexDestroyMexFunction", referenced from:

<initial-undefines>

"_mexFunctionAdapter", referenced from:

<initial-undefines>

ld: symbol(s) not found for architecture arm64

Any permanent solution from MATLAB staff to fix this issues would be highly appreciated. Conversion to C++ API is not an option. Although the resulting C++ Mex code works, it is 25 times slower than the C version.

[William]

I am seeing this error too with R2024a and R2025a. 100% agree fix is needed due to performance issues in C++ API.

[Oliver Woodford]

Just came across this error, myself. Infuriating.

[E Bruce]

any movement from matlab on this issue? really maddening.

the solutions given are fine if compiling mex files directly.

i am using a library that relies on some linear algebra which relies on cpp to speed up the computations.

the mex is burried deep in the library....

Answer 1

[Oliver Woodford]

Based on comments to an answer to a similar question, I found adding the following to my mex invocation solved this issue:

mex LDFLAGS="$LDFLAGS -ld_classic" ...   

I'm using MATLAB R2025b on MacOS 15.0 and Apple silicon (M1 Pro). It should be noted that the -ld_classic flag is deprecated, so this won't work forever. I hope MathWorks can find a proper solution by then.

Answer 2

[William]

So, after rooting around I found some posts online about compiling mex functions externally (i.e. without the mex command), and with a little more digging some related to MacOS/Apple Clang. This worked for me to compile my function that was failing with mex

clang++ -I$(MLROOT)/extern/include -shared -L$(MLROOT)/bin/maca64 -lmex -lmx -std=c++20 -O3 -fexperimental-library -march=native path/to/transformFnc.cpp -o path/to/bin/transformFnc.mexmaca64

Where e.g. MLROOT=/Applications/MATLAB_R2025a.app

And of course you can change your flags as needed (I was messing around with parallel execution hence the need for -fexperimental-library). I'm actually kind of glad this issue forced me to learn how to do this, as it seems nice to be able to control compile flags more closely.