mex errors when compiling c code; however the same code compiles perfectly in Mac Cmd line.

Question

Jonathan am 2 Mär. 2016

0
Verknüpfen

Direkter Link zu dieser Frage

https://de.mathworks.com/matlabcentral/answers/271005-mex-errors-when-compiling-c-code-however-the-same-code-compiles-perfectly-in-mac-cmd-line

Beantwortet: Jonathan am 3 Mär. 2016

Akzeptierte Antwort: Jonathan

VerboseMexOutput.pdf

In MATLAB Online öffnen

For background:

I have a large simulation that I have built in Matlab, and I would like to incorporate a C-based model as a subroutine. To be clear, I need to run some MATLAB code, then the C code, then MATLAB again. The C code is rather complex, living in its own 84-file folder.

I can successfully compile that C code in the Mac terminal via

make cModel

and the compiled code runs as expected. But I now need to get MATLAB to run that C code , and it is here that I am struggling.

The MATLAB bit:

My understanding is that, to get C code that I can run from MATLAB via coder.ceval, I need to compile the C model via the mex command (I've tested that the terminal-compiled C does not run when called by coder.ceval - please correct me if I'm wrong!).

Compiling with

mex cModel

gives

Error using mex
Undefined symbols for architecture x86_64:
"_derivs", referenced from:
      _main in cModel.o
etc... (another 10 C functions considered undefined)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Which seems odd, as my c compiler is perfectly happy with cModel when not called from MATLAB. Any help on how to fix this error would be much appreciated!

Edit: I should probably add that I know I could blindly add in the names of extra C files in the cModel folder to the mex command; although that would mean adding up to 80 filenames with unclear priority/ordering, which C does care about... Regardless, the main code cModel.c does contain the 'include' commands necessary for a normal c compiler to successfully compile - clearly there is something I really don't understand about mex that is causing this compile problem.

Edit2: Blindly adding all C files to mex removes the above errors (no idea why) and replaces them with

Error using mex
Undefined symbols for architecture x86_64:
  "_mexFunction", referenced from:
     -exported_symbol[s_list] command line option

which I'm trying to solve now.

Many thanks, Jonathan

PS. Verbose compile attached (for R2014b Mac, run inside the folder containing cModel)

0 Kommentare
-2 ältere Kommentare anzeigen-2 ältere Kommentare ausblenden

Melden Sie sich an, um zu kommentieren.

Melden Sie sich an, um diese Frage zu beantworten.

Answer 1

Jonathan am 3 Mär. 2016

0
Verknüpfen

Direkter Link zu dieser Antwort

https://de.mathworks.com/matlabcentral/answers/271005-mex-errors-when-compiling-c-code-however-the-same-code-compiles-perfectly-in-mac-cmd-line#answer_212141

In MATLAB Online öffnen

For future internet trawlers searching after a solution, here is mine:

SOLUTION

Use

system('Terminal input string')

to access terminal functionality in MATLAB. This allows MATLAB to run C programs without ever having to interact with this mex nonsense. This method DOES prevent passing variables or vectors directly from C into MATLAB (you would need to save a file in C, then read that file into MATLAB) but it does work wherever you have working C code.

NOT A SOLUTION BUT POSSIBLY USEFUL

As for how far I got on making mex work... Mex will not work directly on C files. You need to build a wrapper to call the C function. This cute fact is a significant number of links and google searches through the MATLAB documentation but can be sorta found here. The following trivial function (saved in the model folder) gets me most of the way there:

    \*function mexWrapper*\
    #include "mex.h"
    void mexFunction( )
    { cModel(); }

Using mex('cModel.c' 'mexWrapper.c') in MATLAB will now cause errors solely due to the cModel call inside mexFunction needing defined input variables to match main() in cModel.c's file. I have not bothered to solve that (the C model I'm working with makes that complicated), but hopefully future readers find this useful.