Fortran module link failure

Question

I am new to Fortran, so maybe this is a straightforward question, but I haven't found any solution that works by looking through similar posts on SO.

My problem is that when I attempt to compile my main program in testsrft.f95 that uses a module srftModule defined in srft.f95 by executing

1. gfortran -c dfft.f
2. gfortran -c srft.f95
3. gfortran -c testsrft.f95
4. gfortran dfft.o srft.o testsrft.o -o testsrft

(Subroutines in srftModule require the Fortran77 code in dfft.f), I get the linker error

testsrftF.o: In function `MAIN__':
testsrftF.f95:(.text+0x98): undefined reference to `fftofmat_'
collect2: ld returned 1 exit status

The module's defined as follows

module srftModule
   implicit none
   contains
   ... (some subroutines)

   subroutine fftofmat(A)
     implicit none
     real*8, dimension(:, :), intent(inout) :: A
     ...
   end subroutine fftofmat

   ... (some more subroutines)

end module srftModule

And in my main file, I have

program testsrft
   use srftModule
   implicit none

   ...(code to initialize a 10x10 matrix A)
   call fftofmat(A)

 end program testsrft

Why is the linker complaining?

Answer 1

Some background:

• MAIN__ is the symbol that gfortran uses for the main program.
• Typically compilers mangle the symbol names for module procedures to include the name of the host module. In gfortran's case the symbol looks something like __modulename_MOD_procedurename.

The symbol quoted in the undefined reference error does not match that pattern for symbols for module procedure references. All together, that means that in the main program the compiler doesn't think that fftofmat is a module procedure - that's the problem that you need to solve. This is contrary to the code that you show, so things I'd look for...

• Is the code that you show really the code you are using (versus the code that you think you typed in/think is relevant) - that use statement is there, the module procedure name is spelt correctly, there's no private statement in the module, the reference in the main program isn't in an internal procedure with the host associated name being hidden somehow, etc?
• Are the source files all compiling without error? Are there "left-over" mod files from a previous successful compile that could be getting picked up in preference to the mod files from the current compile?

While I don't think this is the cause of your problem, note that some systems are sensitive to the ordering of object files and libraries (more so) in the link step - symbols are searched for in the files that follow the file that references a particular symbol on the command line. To be robust you should order your object files the other way around.