Help with gfortran and mex with 2014b on Windows 7 64bit

I am trying to link gfortran (Minigw-w64) with Matlab 2014b on 64bit Windows 7. I have downloaded and run gnumex. If I call "mex -setup" and I can see the gcc compiler in Matlab, with the correct path. I am trying to test my setup on a minimal hello world! program, "hello.f". I can call "gfortran hello.f" from the Windows command line and get the correct result. I have added gcc to my system path. However, when I call "mex -v hello.f" in Matlab, I get the following output:

    Cannot export mexFunction: symbol not defined 
    C:\Users\JP\AppData\Local\Temp\mex_9AxT5n\hello.obj:hello.f:(.text+0x2f): undefined reference to `_gfortran_st_write' 
    C:\Users\JP\AppData\Local\Temp\mex_9AxT5n\hello.obj:hello.f:(.text+0x47): undefined reference to `_gfortran_transfer_character_write' 
    C:\Users\JP\AppData\Local\Temp\mex_9AxT5n\hello.obj:hello.f:(.text+0x4f): undefined reference to `_gfortran_st_write_done' 
    C:\Users\JP\AppData\Local\Temp\mex_9AxT5n\hello.obj:hello.f:(.text.startup+0x1c): undefined reference to `_gfortran_set_args' 
    C:\Users\JP\AppData\Local\Temp\mex_9AxT5n\hello.obj:hello.f:(.text.startup+0x30): undefined reference to `_gfortran_set_options' 
    collect2.exe: error: ld returned 1 exit status 
    link command: gcc -shared C:\Users\JP\AppData\Roaming\MATHWO~1\MATLAB\R2014b\gnumex\mex.def -o hello.mexw64 -LC:\Users\JP\AppData\Roaming\MATHWO~1\MATLAB\R2014b\gnumex -s C:\Users\JP\AppData\Local\Temp\mex_9AxT5n\hello.obj -llibmx -llibmex -llibmat 

      E:\MATLAB\R2014B\BIN\MEX.PL: Error: Link of 'hello.mexw64' failed.

Any advice is highly appreciated!

[dpb]

Did you write a mex interface routine or are you trying to build the same executable you ran as a standalone program? The latter won't work; mex builds a DLL, not an executable.

[Jon Paul Janet]

I am actually trying to re-mex a fortran function from source that is currently only available as a .mexa64 (I want to get the .mex64 version). I was getting a whole lot of Link failed errors, so I thought I would test a minimal example. If I try and build the routine "timestwo.F" exactly as per timestwo.F, I get a laundry list of errors - basically everything is " Unclassifiable statement at (n) ", n=1,2...

[dpb]

Well, getting one of the sample cases to compile/link/execute is always a first step w/ a new setup. I've not tried to get gfortran working so don't have any directly-applicable help, sorry.

But, the latter looks like a problem w/ source form or the preprocessor or the like in the file not being interpreted correctly.

As James Tursa notes, the default mex setup assumes old fixed format source as most compilers will assume with .f/F, the capital will invoke the preprocessor generally as well. I presume gfortran behaves that way, too?

Try to build that source externally, too, to make sure it's kosher there then retreat back to mex script.

[Jon Paul Janet]

Yes, from what I've read the .F turns on the preprocessor. Turns out I can't compile the sample case externally - unclassifiable statements all the way, using the source straight from Mathworks. I guess it might not be gfortran compatible as it is certainly not interpreting correctly. I only know the most basic fortran so I guess I am out of my depth here. Thanks for your time anyway!

[dpb]

I'm certain gfortran can compile the files; the problem has to do with I don't know its preprocessor nor what it takes for its switches to ensure its using the right source code form--the Matlab source (unless they've all of a sudden changed which I'd doubt) does require fixed source form (that's the old column 7 thru 72 with statement numbers in 1-5, continuation 6 style).

Post a section of the listing w/ errors; gotta' be a fairly easy fix but will need to look at the switches for the compiler.

[Jon Paul Janet]

Thank you so much for the advice. Yes, I am aware of the odd column spacing business - the Fortran source seems to respect it. From what I follow of the gfortran documentation, the old column style should have .F extension. Here is the result of trying to build the file:

C:\Users\JP>gfortran timestwo.F -o tim timestwo.F:25.6:

      mwPointer plhs(*), prhs(*)
      1
Error: Unclassifiable statement at (1)
timestwo.F:29.6:

      mwPointer mxGetPr
      1
Error: Unclassifiable statement at (1)
timestwo.F:30.6:

      mwPointer mxCreateDoubleMatrix
      1
Error: Unclassifiable statement at (1)
timestwo.F:32.6:

And so on. The source is exactly as in timestwo.F. Taking out the comments it reads:

      subroutine mexFunction(nlhs, plhs, nrhs, prhs)
C     Declarations
      implicit none
C     mexFunction arguments:
      mwPointer plhs(*), prhs(*)
      integer nlhs, nrhs
C     Function declarations:
      mwPointer mxGetPr
      mwPointer mxCreateDoubleMatrix
      integer mxIsNumeric
      mwPointer mxGetM, mxGetN

etc. So it never really gets off the ground. The list of valid gfortran switches is here. I have tried the fixed and freeform options (although it should get these from the extension I believe). EDIT: I should also mention that I have included the header file fintrf.h which is #inlcuded in the fortran source

[dpb]

OK, that's what I suspected--the preprocessor isn't getting invoked.

mwPointer plhs(*), prhs(*)

mwPointer is a #define in fintrf.h and should be replaced by the preprocessor with the appropriate INTEGER kind before the compiler is invoked. So, either the fpp isn't actually running or the needed variable isn't set to invoke the conditional. That section of fintrf.h contains

#if defined(__LP64__) || defined(_M_AMD64) || defined(__amd64)
# define mwpointer integer*8
# define mwPointer integer*8
# define MWPOINTER INTEGER*8
#else
# define mwpointer integer*4
# define mwPointer integer*4
# define MWPOINTER INTEGER*4
#endif

So, ensure that the preprocessor

a) does get called, and

b) the appropriate 64-bit definition is defined.

[Jon Paul Janet]

Glory be! It complies on my command line. I was using a bad copy of fintrf.h (I grabbed it online and it was out of date). So now that works. But the example still gives me unclassifiable statements if I try and mex it? i.e., timestwo.F:13.6:

      mwPointer plhs(*), prhs(*)                                         
      1 
Error: Unclassifiable statement at (1) 
timestwo.F:16.6:

Now, Matlab is presumably linking to the updated version of the header in the extern folder, which is the one I was able to compile with. Somehow the mex is not activating the preprocessor?

[dpb]

There should be an up-to-date copy of fintrf.h in the distribution (altho I don't think it's changed in quite a number of releases) in the ..\external\include directory.

Need to ensure that's the right location specified in the INCLUDE environment variable; obviously one is being found or you'd have the error of 'file not found' when it reached the INCLUDE statement.

That does seem to leave the alternative the preprocessor wasn't called since the MWPOINTER declaration hasn't gotten substituted at all. Even if the -D weren't set for one of the 64-bit options since neither the #if nor the #else path was executed as MWPOINTER wasn't substituted at all seems to be so that it just didn't do anything at all.

For fpp here I had to use the

   /m     Do macro expansion outside of preprocessor lines

switch to make fintrf.h work correctly. As said, not sure what gfortran does about a preprocessor; whether it packages a specific version with the distribution or relies on whatever is on the system independent.