Compiling C code for 64-bit Matlab on Intel MAC

Question

Hi all,

I need compile a piece of C code to be called from matlab (mex compiling). I am doing that on an intel mac and, since I am using Matlab's R2010a (7.10.0.499), I'd like to compile the C code into a version for 64-bits. For whatever reason, just doing mex with the -arch=maci64 option did not seem to work...

As a way around, I am compiling the C code to a mexmaci64 file directly on the command line. I used the gcc calls made by mex (with the -v option on) as a starting point. I managed to compile the C code to an object file, but it looks like I am not compiling the C code to the correct architecture.

Does anyone know how to correct the gcc calls below so the C code gets compiled to 64-bits intel macs?

Details are listed below.

As always, any help greatly appreciated...

Keep thirsty, my friends. :p

G

DETAILS:

Here is how I did the compilation and linking:

gcc -c  -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -fexceptions -D MACVERSION  -DMX_COMPAT_32 -O3 -DNDEBUG  "BoxQP.c"

gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-exported_symbols_list,/Applications/MATLAB_R2010a.app/extern/lib/maci64/mexFunction.map -o  "BoxQP.mexmaci64"  BoxQP.o  -L/Applications/MATLAB_R2010a.app/bin/maci64 -lmx -lmex -lmat -lstdc++

Here are the warnings I get:

ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmx.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmex.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmat.dylib, file is not of required architecture

Ignoring the warnings and calling the BoxQP function from matlab results in the following error message:

??? Invalid MEX-file '/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64':
dlopen(/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64, 1): no suitable image found.  
Did find: /Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64: mach-o, but wrong architecture.

PS: I tried changing the -DMX_COMPAT_32 flag to -DMX_COMPAT_64 but I do get the same warnings and same error...

PPS: I guess it may be relevant to mention that I am using Mac OS X 10.5.8 (the "tropical"/plain-vanilla Leopard, i.e., not the snow Leopard).

PPPS: The same happens with the yprime.c example provided by MATLAB

Answer 1

I have made some progress in this question.

The -arch=maci64 option was not working because there existed a mexopts.sh script along the way that prevented the call to use the matlab version of that script.

However, I now get a new kind of linking error.

I compile the C code with the call:

mex -v -arch=maci64 -DMACVERSION  BoxQP.c utils.c

This results in three gcc calls (the -v option lets us see what mex is doing under the hood).

The first two are:

gcc-4.0 -c  -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5  -fexceptions  -DMACVERSION -DMX_COMPAT_32 -O2 -DNDEBUG  "BoxQP.c"
gcc-4.0 -c  -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5  -fexceptions  -DMACVERSION -DMX_COMPAT_32 -O2 -DNDEBUG  "utils.c"

These execute fine: I called them from the command line and the object files where created (hopefully, for the correct architecture, since there is an option -arch x86_64 in the call to gcc).

The third call (linking?) to gcc is:

gcc-4.0 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2010a.app/extern/lib/maci64/mexFunction.map -o  "BoxQP.mexmaci64"  BoxQP.o utils.o  -L/Applications/MATLAB_R2010a.app/bin/maci64 -lmx -lmex -lmat -lstdc++

This yields the following error message:

Undefined symbols:
"_cblas_daxpy", referenced from:
    _BoxQP in BoxQP.o
    _BoxQP in BoxQP.o
"_cblas_dcopy", referenced from:
    _BoxQP in BoxQP.o
    _BoxQP in BoxQP.o
    _maxeig in utils.o
"_cblas_dgemv", referenced from:
  _BoxQP in BoxQP.o
  _maxeig in utils.o
  _maxeig in utils.o
"_mexFunction", referenced from:
   -exported_symbols_list command line option
"_cblas_dscal", referenced from:
    _BoxQP in BoxQP.o
    _maxeig in utils.o
    _maxeig in utils.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Needless to say, BoxQP.c and utils.c do contain calls to the BLAS functions cblas_daxpy, cblas_dcopy, cblas_dgemv, cblas_dscal.

Two questions from these errors:

1. Aren't the BLAS functions defined in /Developer/SDKs/MacOSX10.5.sdk?

   If so, why does the linking fail?

2. What does the '_mexFunction' reference amounts to?

As always, any help is greatly appreciated.

Best,

G.