Error when compiling Fortran MEX file with mxCreateStructMatrix

Question

Josh G. 2020-5-15

1
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/525763-error-when-compiling-fortran-mex-file-with-mxcreatestructmatrix

评论： 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?

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

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

Answer 1

Josh G. 2020-5-15

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/525763-error-when-compiling-fortran-mex-file-with-mxcreatestructmatrix#answer_432694

在 MATLAB Online 中打开

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更早的评论隐藏 6更早的评论

Josh G. 2020-5-29

在 MATLAB Online 中打开

Interestingly, mex adds -fdefault-integer-8 automatically, even though it doesn't appear in the mexopts file. You can see this in the output of mex -v:

Building with 'gfortran'.
/usr/bin/gfortran -c -DMATLAB_DEFAULT_RELEASE=R2017b  -DUSE_MEX_CMD    -I"/usr/local/MATLAB/R2019b/extern/include" -fexceptions -fbackslash -fPIC -fno-omit-frame-pointer -fdefault-integer-8 -O2 -mtune=native "/home/user/Documents/MATLAB/timestwo.F90" -o /tmp/mex_9181185797012_69247/timestwo.o
/usr/bin/gfortran -c -DMATLAB_DEFAULT_RELEASE=R2017b  -DUSE_MEX_CMD    -I"/usr/local/MATLAB/R2019b/extern/include" -fexceptions -fbackslash -fPIC -fno-omit-frame-pointer -fdefault-integer-8 -O2 -mtune=native "/usr/local/MATLAB/R2019b/extern/version/fortran_mexapi_version.F" -o /tmp/mex_9181185797012_69247/fortran_mexapi_version.o
/usr/bin/gfortran -pthread -shared -O -Wl,--version-script,/usr/local/MATLAB/R2019b/extern/lib/glnxa64/fortran_exportsmexfileversion.map /tmp/mex_9181185797012_69247/timestwo.o /tmp/mex_9181185797012_69247/fortran_mexapi_version.o   -Wl,-rpath-link,/usr/local/MATLAB/R2019b/bin/glnxa64 -L"/usr/local/MATLAB/R2019b/bin/glnxa64" -lmx -lmex -lmat -lm -L"/usr/lib64" -lgfortran -o timestwo.mexa64
MEX completed successfully.

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. 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.

请先登录，再进行评论。