Has the MEX function (mxGetComplexDoubles) been deprecated in R2024b?

I am preparing a MEX file that includes the function: (mxGetComplexDoubles).

I tried to compile and link it to get the executable file (*. mexw64) corresponding to the source file: (*.F) using either of the following commands:

mex -R2018a filename.F

mex -R2018a -I"C:\Program Files\MATLAB\R2024b\extern\include" -L"C:\Program Files\MATLAB\R2024b\extern\lib\win64\microsoft" -llibmex -llibmx filename.F

The compilation was successful; however, the linking was not because:

unresolved external symbol mxgetcomplexdoubles800

This happened despite my file containing the command (mxGetComplexDoubles) rather than the command (mxGetComplexDoubles800).

Surprisingly, upon searching for (mxGetComplexDoubles), I found that it is not there in:

"C:\Program Files\MATLAB\R2024b\bin\win64\libmex.dll"

"C:\Program Files\MATLAB\R2024b\bin\win64\libmat.dll"

My questions:

1. Has the function (mxGetComplexDoubles) been deprecated in R2024b?
2. What should I do in that case?

[dpb]

Well, enough poking finally got to the R2024b doc; it says it still exists "in the the interleaved complex API" although I'm not sure what that library name is. I also found a link about <Upgrade MEX Files to Use Interleaved Complex API> that may help...

[Magdy Hanna]

Not helpful

[dpb]

Why not? It <links to "Do I Need to Upgrade..."> further that says to continue present without modifying code, switch to -R2017a instead....that link contains a table, one entry of which contains...

"I do not plan to update my code.

If your MEX functions use complex numbers, then you have chosen to opt out. MathWorks recommends that you build using the compatibility flag -R2017b.

If your code processes complex numbers, you might notice a performance impact as MATLAB accesses the compatibility interface."

But clearly with the -R2018a switch, you're forced into complying with the new arrangement whether you like it or not.

[Walter Roberson]

In MacOS the file bin/maci64/libmx.dylib defines _mxGetComplexDoubles_800

[Magdy Hanna]

I am using Interleaved complex, and consequently I have to select -R2018.

I think my question has not been clearly answered.

[dpb]

I guess i misread the meaning of the initial -- i thought you were using complex variables but not the interleaved interface...

I don't have R2024 installed, but in R2021b that I do have, mxGetComplexDoubles is in libmix.lib as expected, however, the exported symbols are

   "MXGETCOMPLEXDOUBLES800"
    "__imp_MXGETCOMPLEXDOUBLES800"
    "__imp_mxGetComplexDoubles_800"
    "mxGetComplexDoubles_800"

The error you got of

unresolved external symbol mxgetcomplexdoubles800

would be expected result because Fortran by default generates all uppercase symbol names as is shown above...the "800" comes because the compiler automagically adds the number of argument bytes onto the symbol name unless a compiler switch is set expressly to not do so.

Now, why it's apparently creating the lowercase name rather than expected uppercase I dunno...but that looks to me to be the issue.

It's been a long time since I messed with details of libraries; I recalled I thought that the MS lib utility would export a list of the library symbols, but I couldn't get the version installed here now with VS to do so...I ended up grep-ing the lib file for the case-insensitive symbol name and then parsing it down to the specific ones of interest--a lot of work for what should be a trivial exercise. But, you can grep or otherwise do a text search inside the libmx.lib library file for the symbol string and you should find, I expect, the same result.

ADDENDUM

Indeed, it had been a really long time...the utility is nm.exe, not the lib command...it creates a really long list, but if you have installed mingw64, it is installed automatically as one of the developer tools.

nm -g -U -W libmx.lib >mxlib.lst

will give you a (very long) text file mxlib.lst that you can search for the specific symbol name...the result will look something like

C:\MLR2021b\extern\lib\win64\microsoft>grep -i -A4 -B1 mxgetcomplexdouble mxlib.lst
.text
__imp_MXGETCOMPLEXDOUBLES800
MXGETCOMPLEXDOUBLES800
.idata$4
.idata$5
.idata$6
.text
--
.text
__imp_mxGetComplexDoubles_800
mxGetComplexDoubles_800
.idata$4
.idata$5
.idata$6
.text

C:\MLR2021b\extern\lib\win64\microsoft>

Answer 1

[Walter Roberson]

No, mxGetComplexDoubles has not been deprecated in R2024b.

The problem is you called it from Fortran and Fortran is calling the name in all lower-case.

You can add a C function named mxgetcomplexdoubles800 that does nothing but call mxGetComplexDoubles_800

Or you can use BIND on the Fortran code side; https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2023-0/bind-c.html (requires Fortran 2003 or later)

[dpb]

But, that implies something is broke in the mex make file...it should be creating the expected uppercase symbol names. It would be interesting/informative to see the compilation output if would rerun with the -v verbose option...

@Magdy Hanna hasn't told us which compiler he's using; after my continued whining about Mathworks not supporting gfortran on Windows, there was an update note that it is now supported for lastest release.

I have yet to download/install new versions so can't try/test here because the only "supported compiler" is the old Intel ifort which is no longer downloadable from Intel and TMW apparently didn't create an archive arrangement with Intel. So, older releases seemingly are stuck unless one previously downloaded ifort. That they make it so difficult to just use the currently-installed local Fortran compiler is maddening...

[dpb]

I don't have a way to actually build a mex file directly, but do have Intel OneAPI.2025 installed...if I compile the demo convec.F that uses getMxComplexDoubles, then

C:\...\Documents\MATLAB\Work>ifx -nologo -fpp -c convec.F -o convec.o
C:\...\Documents\MATLAB\Work>nm convec.o
...
0000000000000000 T CONVEC
                 U MEXERRMSGIDANDTXT800
0000000000000170 T MEXFUNCTION
00000000000012c0 b MEXFUNCTION$X
0000000000000c80 b MEXFUNCTION$Y
0000000000000000 b MEXFUNCTION$Z
                 U MXCOPYCOMPLEX16TOPTR800
                 U MXCOPYPTRTOCOMPLEX16800
                 U MXCREATEDOUBLEMATRIX800
                 U MXGETCOMPLEXDOUBLES800
                 U MXGETM800
                 U MXGETN800
                 U MXISCOMPLEX800
...
C:\Users\...\MATLAB\Work>

which did generate the all uppercase symbols as expected. I'm sure the older ifort used same convention.

However, if I use gfortran instead,

C:\Users\...\MATLAB\Work>gfortran  -c convec.for -o convec.o
C:\Users\...\MATLAB\Work>nm convec.o
0000000000000000 T convec_
                 U mexerrmsgidandtxt800_
00000000000001d0 T mexfunction_
                 U mxcopycomplex16toptr800_
                 U mxcopyptrtocomplex16800_
                 U mxcreatedoublematrix800_
                 U mxgetcomplexdoubles800_
                 U mxgetm800_
                 U mxgetn800_
                 U mxiscomplex800_

C:\Users\...\MATLAB\Work>

which converted to all lowercase and added the trailing underscores with default options. That is a different behavior for a Fortran compiler from any I have used previously; the documentation confirms this is the default behavior. There is bound to be a way to change it, but my looking so far hasn't uncovered precisely how to do so...there is a switch to stop the decoration but I haven't found the capitalization directive.

Ergo, it looks like we can assume @Magdy Hanna isn't using ifx and may be trying to link against libraries buildt for Intel/MS and not gfortran? We don't have sufficient detail to know; we only have the link failure message to look at.

[dpb]

Well, a more intensive search has shown that gfortran does NOT have the ability with a compiler switch to force symbol names to upper case. The only way with supported tools would, in fact, be the use of the c-binding module, but that also implies other effects on calling conventions.

It still appears to me something is broken in either the install @Magdy Hanna is using or in the libraries or make file that the mex command is trying to link against the wrong vendor library when compiling with other than the Intel compiler.

[Magdy Hanna]

The problem was not solved.

[Walter Roberson]

Did you try using BIND in the fortran code?

[Magdy Hanna]

No

[Walter Roberson]

You can add a C function named mxgetcomplexdoubles800 that does nothing but call mxGetComplexDoubles_800

Or you can use BIND on the Fortran code side; https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2023-0/bind-c.html (requires Fortran 2003 or later)

[dpb]

@Magdy Hanna, you've still not told us which Fortran compiler you're trying to use.

It would be most helpful to see the result of

mex -setup

and then also the output of recompiling with the "-v" option.

The mismatch in naming conventions indicates something is not correct in the setup or the choice of libraries or there is a bug in the distribution libraries in not being built to match the installed compiler.

One may be able to force the naming convention mismatch to go away with BIND, but I'd have little confidence without knowing the above details it will actually link correctly.

[dpb]

"Or you can use BIND on the Fortran code side;..."

The definition of "interoperable" from the Fortran Standard technical terms is:

"interoperable (15.2) : The property of a Fortran entity that ensures that an equivalent entity may be defined by means of C."

Section 15.2 states

15.2 Interoperability between Fortran and C entities

The following subclauses define the conditions under which a Fortran entity is interoperable. If a Fortran entity is interoperable, an equivalent entity may be defined by means of C and the Fortran entity is said to be interoperable with the C entity. There does not have to be such an interoperating C entity. [emphasis added-dpb]

So, while the Standard defines the syntax of Fortran that will produce a matching interface to C, it does not specify the implementation or that there necessarily will even be one. The implementation is left to the developer and binding is still dependent upon there being a conforming C compiler. It's far more than just changing the name, BIND() also changes the calling conventions from those used in Fortran to those of C.

While the Standard doesn't require a conforming Fortran compiler vendor to produce a companion C compiler, both Intel and gfortran do have at least one. Unlike IntelOneAPI, gfortran is not a full Fortran compiler but a front end to gcc, so it comes along for the ride.

I'm still convinced @Magdy Hanna is using one Fortran compiler and trying to link against libraries built with a different and non-conforming one but unless and until is willing to provide the additional missing information, not much else to be done but to point out the issue.