Error when compiling Fortran MEX file with mxCreateStructMatrix

1 次查看（过去 30 天）
Josh G.
Josh G. 2020-5-15
评论： Josh G. 2020-6-1
I'm trying to create a struct as an output of a MEX file, but when I try to compile the file, I get errors about the function mxCreateStructMatrix not being defined. The exact error is:
Error: Function ‘mxcreatestructmatrix730’ at (1) has no IMPLICIT type; did you mean ‘mxcreatedoublematrix730’?
It would seem that the library that defines mxCreateStructMatrix isn't being linked, but I don't know which library is supposed to define the function. My library string from
mex -v filename.F90
is
LINKLIBS : -Wl,-rpath-link,/usr/local/MATLAB/R2019b/bin/glnxa64 -L"/usr/local/MATLAB/R2019b/bin/glnxa64" -lmx -lmex -lmat -lm -L"/usr/lib64" -lgfortran
My guess is that the library is supposed to be defined by "-lmx," but ld is able to find the library without a problem. What could cause the function not to have a type defined?

请先登录，再回答此问题。

采纳的回答

Josh G.
Josh G. 2020-5-15
After some more testing I figured out what the problem was. The precompilation was failing because each function has to be defined with a type of "mwPointer," so adding the line
mwPointer :: mxCreateStructMatrix
to my MEX file fixed the problem.
  8 个评论
显示 6更早的评论
James Tursa
James Tursa 2020-5-29
编辑：James Tursa 2020-5-29
OK. So maybe there is a different interface for the entry point for Fortran. I would not have expected that, and frankly don't know why they would even do that in the first place. Regardless, I still think adding the -fdefault-integer-8 option behind the user's back is inherently a bad idea since it might screw up the user's code. It would have been better to simply specify it as INTEGER*8 or mwPointer in the doc to make the intent explicit. I don't even know if there are any other routines in the API that use the default integer besides mexFunction. I feel the same way about this that I do about the silly /fixed option that they include in their mex build files that screw up the user trying to use free format code. I complained about this several years ago but it is still there. You should delete it if you haven't already.
Thanks for the post ... I learned something from this discussion.
I wonder what would happen if you built a mex function that linked some Fortran object code containing an exported MEXFUNCTION with some C object code containing an exported mexFunction ... which one would get called? Would it depend on the link order? Or is there a preferred order that it searches for the entry point? I'm not asking you to do this ... I am just wondering what would happen. I haven't had access to a Fortran compiler for quite some time so can't check this myself.
Josh G.
Josh G. 2020-6-1
Yes, MathWorks does several things wrong with their Fortran MEX implementation, but it's been said elsewhere in MATLAB Answers that Fortran is the red-headed stepchild of the MEX languages.
Using the non-standard integer*4 and integer*8 instead of the standard KIND specification is wrong, using -fdefault-integer-8 is wrong, using /fixed and supplying examples as FORTRAN 77 source is wrong, and supporting GCC for C and C++ MEX but not GFortran for Fortran MEX on Mac and Windows is wrong.
Fortunately I don't think they include a GFortran equivalent of /fixed on Linux, but I've had to deal with removing it on Windows machines and it's annoying.
As one example of how their non-standard integer/real notation could cause problems, I write MEX files that interface with native Fortran programs using the standard KIND specification. It's not inconceivable that the MEX file could be compiled on a system where (taking real64 from the ISO_FORTRAN_ENV module) real(real64) and real*8 aren't the same thing.

请先登录，再进行评论。

更多回答（0 个）

类别

在 Help Center 和 File Exchange 中查找有关 Write C Functions Callable from MATLAB (MEX Files) 的更多信息

标签

产品


版本

R2019b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by