C/Fortran callback to MATLAB
Show older comments
I have a large library (~100K lines of code) written in modern Fortran, out of which I need to call only one function with the following C-signature,
#include <stdint.h>
void runFoo (
// nd
int32_t *
// getFuncFromMatlab(nd, Point(nd)): procedure pointer to the MATLAB function
, double (*)(int *, double [])
// input character vector
, char []
// the length of the input chracter vector
, size_t *
);
Note that this function contains a callback to MATLAB. In other words, MATLAB calls this function, and this DLL function has to call another function in MATLAB provided by the original calling MATLAB function. I can generate a DLL from this library, and it loads in MATLAB via lodlibrary() with the above C header. However, that is no help, and I believe I am seriously missing some fundamental step to make this callback work. What is the best approach to solve this problem? MATLAB mex file compilation is no help either, as it apprently cannot even understand the syntax of modern Fortran, for example, module keyword. appreciate you help very much.
As a side note, as much as I find MATLAB a great standalone computing tool, I also find it terrible for any interoperation with any other languages. Hope this issue gets fixed. Are there any interoperation capabilities in MATLAB that would be equivalent to the simple, yet extremely powerful ctypes package of Python?
19 Comments
Walter Roberson
on 14 Sep 2019
I believe that you are mistaken about support for modules.
If you are using Windows or Mac then Fortran support is by way of Intel Parallel Studio XE Fortran. For that compiler, files with extension .f90 are assumed to be Fortran 90/95 free form. You can specifically request that extensions beyond that be marked as errors by adding -std90 or -std95
If you are using Linux then support is through gfortran. You might need to add -std=f95
A.B.
on 14 Sep 2019
Walter Roberson
on 14 Sep 2019
Edited: Walter Roberson
on 30 Mar 2020
Bruno Luong
on 14 Sep 2019
Edited: Bruno Luong
on 14 Sep 2019
Does that mean Mex cannot compile the library?
Mex No (actually a MEX file is an DLL - so library - under windows just callable only under MATLAB), but MCC yes, see my post.
James Tursa
on 14 Sep 2019
Are you asking if the argument with this signature
double (*)(int *, double [])
which is a pointer to a function that takes an int pointer and double pointer as input arguments and returns a double, can point to an arbitrary MATLAB function like an m-file?
A.B.
on 14 Sep 2019
James Tursa
on 15 Sep 2019
Edited: James Tursa
on 15 Sep 2019
Two quick comments:
1) Whether or not you can use modern Fortran features depends entirely on your compiler, not on MATLAB or mex. The only catch is you may need to go into the mex configuration files and remove the silly /fixed option that TMW keeps insisting on including.
2) I don't know of any way to directly interface a C function pointer with a MATLAB m-file. Maybe there is a way with some of the loadlibrary capabilities, but I don't use loadlibrary so can't advise on this. For mex routines, typically one would use mexCallMATLAB for this.
A.B.
on 15 Sep 2019
Bruno Luong
on 15 Sep 2019
Edited: Bruno Luong
on 15 Sep 2019
Why can't you compile your library as *.lib then link it whith a C/C++/FORTRAN MEX interface function?
You need to figure out suitable name mangling, calling convention to suit both sides but that all you need to do (well beside of course programming the interface function).
James Tursa
on 18 Sep 2019
"You need to figure out suitable name mangling ..."
If you are using C++, I would highly advise using the extern "C" { ... } feature to avoid all name mangling.
A.B.
on 21 Mar 2020
James Tursa
on 21 Mar 2020
Edited: James Tursa
on 21 Mar 2020
Is this function pointer argument:
double (*)(int *, double [])
supposed to call back and actually call a MATLAB m-file function at run time? I.e., You compile your library, but you don't know at compile time what the function pointer will point to. Then at run time, you pass in a string with the name of the MATLAB function you want that function pointer to use for a call back, and you want to make that connection at run time. Is that what you are trying to do? If so, this sounds doable and mexCallMATLAB would be the method to use, and I can write up a short example showing how to do this if needed.
HOWEVER, I would need to know what the function behind this function pointer is doing with the arguments. Specifically, is the data behind the int * and double [ ] input argument pointers read-only or is it supposed to get modified by the function. I need a much wider context of how this function will be used in your code to determine if there will need to be data copying going on behind those data pointers.
Maybe you could write up a short example using m-code and pseudo code or English to show what you want the code to do.
James Tursa
on 31 Mar 2020
Edited: James Tursa
on 31 Mar 2020
One final question. These input arguments
double (*)(int *, double [])
are coming from native C/C++ memory via malloc or local variables etc. and not from MATLAB generated memory via mxMalloc etc.?
A.B.
on 1 Apr 2020
Walter Roberson
on 16 Apr 2020
[You deleted a question before my response could go up, and you do not permit contacts in your profile, so the below is in response to the question you asked, not to the above Question]
- move the dylib to the /usr/lib folder on macOS, which macOS did not allow
You have to sudo in order to do it, but it does allow that.
I am surprised to see that in the year 2020, MATLAB and Apple still cannot resolve their problems like grown-ups and come to an agreement to recognize and respect each other's software.
Whether they do that or not, the C DLL is not Apple's software and it is not Mathworks software either, it is your software. Mathworks might have permitted Apple to scan its software to ensure that it is "safe", but Mathworks could not possibly have given Apple permission to scan your software because your software did not exist at the time Mathworks had MATLAB certified.
As far as Apple is concerned, SIP did what it is supposed to do: Prevent an unknown untrusted DLL from being used. Apple's SIP does not know that you, the user, created the DLL yourself: as far as it knows, an untrusted browser extension might have silently downloaded a DLL and is trying to trick MATLAB into running it.
As far as Apple is concerned, anyone who wants to write software that creates DLLs that will be executed by a program covered by SIP, should become a registered Apple developer and go through the process of getting every DLL scanned and certified before use.
If this leads you to the suspicion that Apple believes that end users (not part of the Developer Program) should not be compiling software for their own use, then that is because that is Apple's goal. Apple is pushing for the position that you should either be paying Apple to develop the software you want, or paying a certified third-party developer to develop the software you want. Apple is fond of "walled gardens". It is not (for now) going to prevent you from compiling your own software, but it is going to ensure that (A) you are inconvenienced; and (B) that the software runs in a lower-security context.
A.B.
on 16 Apr 2020
Walter Roberson
on 16 Apr 2020
With regards to /usr/bin :
I find it hard to believe that Apple cannot trust MATLAB. This seems to be more of a corporation rivalry than anything else
Apple cares little what Mathworks thinks. Mathworks is not buying many systems from Apple, and not so many people buy Apple systems specifically to run MATLAB. Mathworks is just another customer of the Developer's Program as far as Apple is concerned.
Apple blew off NVIDIA, which is a $US100B+ company; Mathworks is small potatos by comparison. It isn't a matter of corporate rivalry: Mathworks is too small for Apple to notice. Apple makes decision, and Mathworks just has to live with the decisions.
A.B.
on 16 Apr 2020
Accepted Answer
James Tursa
on 31 Mar 2020
Maybe this can give you the framework you need. I have made some assumptions about how things are connected. You pass in a char string of the MATLAB function you want called, and the callback function inside the C code calls it using some C native memory as input, simple as that.
The code:
// C = callback_test(fun)
// fun = char string containing the MATLAB function name
// C = the result of the callback
#include "mex.h"
#include <stdlib.h>
#include <stdint.h>
void runFoo (
// nd
int32_t *
// getFuncFromMatlab(nd, Point(nd)): procedure pointer to the MATLAB function
, double (*)(int *, double [])
// input character vector
, char []
// the length of the input chracter vector
, size_t *
);
double callback(int *, double []); // The callback function
char *mname; // MATLAB function name
//-------------------------------------------------------------------------
void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
int32_t n = 7;
char *thestring = "testing123";
size_t len = 10;
if( nrhs && mxIsChar(prhs[0]) ) {
mname = mxArrayToString(prhs[0]);
mexPrintf("MATLAB function = %s\n",mname);
runFoo( &n, callback, thestring, &len );
}
}
//-------------------------------------------------------------------------
void runFoo (
// nd
int32_t *nd
// getFuncFromMatlab(nd, Point(nd)): procedure pointer to the MATLAB function
, double (*getFuncFromMatlab)(int *, double [])
// input character vector
, char str[]
// the length of the input chracter vector
, size_t *len
)
{
int i, ind;
double *d;
double result;
// Generate some fake data using C native memory
d = (double *) malloc( *nd * sizeof(*d) );
for( i=0; i<*nd; i++ ) {
d[i] = (double) (i+1);
}
// Call the callback function
ind = *nd; // Just in case an int32_t is not the same as an int
result = getFuncFromMatlab( &ind, d );
// Print the results
mexPrintf("Result = %g\n",result);
mexPrintf("String passed = ");
for( i=0; i<*len; i++ ) {
mexPrintf("%c",str[i]);
}
mexPrintf("\n");
// Deallocate the C native memory
free(d);
}
//-------------------------------------------------------------------------
double callback(int *nd, double d[])
{
mxArray *rhs[1], *lhs[1];
double *pr;
double result;
int i;
mexPrintf("Inside callback for function %s\n",mname);
// Create the input argument
rhs[0] = mxCreateUninitNumericMatrix( *nd, 1, mxDOUBLE_CLASS, mxREAL );
// Copy the data (need to get C native memory into MATLAB memory)
pr = (double *) mxGetData( rhs[0] );
for( i=0; i<*nd; i++ ) {
*pr++ = *d++;
}
// Make the call
if( mexCallMATLAB( 1, lhs, 1, rhs, mname ) ) {
mexErrMsgTxt("Callback didn't work");
}
result = mxGetScalar( lhs[0] );
// Free the temporary variables
mxDestroyArray( lhs[0] );
mxDestroyArray( rhs[0] );
//Done
return result;
}
And some sample runs:
>> mex callback_test.c
Building with 'Microsoft Visual C++ 2013 (C)'.
MEX completed successfully.
>> callback_test('sum')
MATLAB function = sum
Inside callback for function sum
Result = 28
String passed = testing123
>> callback_test('prod')
MATLAB function = prod
Inside callback for function prod
Result = 5040
String passed = testing123
>> callback_test('sin')
MATLAB function = sin
Inside callback for function sin
Result = 0.841471
String passed = testing123
>> sin(1)
ans =
0.8415
>> callback_test('garbage')
MATLAB function = garbage
Inside callback for function garbage
Error using callback_test
Undefined function 'garbage' for input arguments of type 'double'.
2 Comments
James Tursa
on 2 Apr 2020
Edited: James Tursa
on 2 Apr 2020
Alas, I have never used MPI. One of the things I always intended to learn someday but as yet haven't found the time. How did you include the compiler flag? Are you sure it is getting to the compiler? E.g., are you building the mex routine via the mex command and modifying the $COMPFLAGS stuff, or are you building the mex routine outside of MATLAB?
You also mention the MATLB engine. Are you running the mex routine within a MATLAB Engine? Are you trying to run multiple MATLAB Engines in parallel using MPI?
A.B.
on 2 Apr 2020
More Answers (1)
Bruno Luong
on 14 Sep 2019
Edited: Bruno Luong
on 14 Sep 2019
0 votes
Not sure what you mean by "Callback". Callback to me is kind of event trigger function like an SW interruption.
Anyway if you have the compiler, you can compile any MATLAB function in C shared library, and call it from external C program.
I have no idea about FORTRAN, but in the pass I have linked fortran (gcc,g77) with MSVSC/Intel-C, a bit tricky but doable.
Categories
Find more on Write C Functions Callable from MATLAB (MEX Files) in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
