Undefined symbols error when linking object files

So, I have my modules all working (stored in modules.f90), except this part…

module dummy_routines

	contains

		subroutine record_time(sf)

			<DOES SOME FILE HANDLING>
			
		end subroutine
	
end module

This is contained within the modules.f90 file and then generates the dummy_routines.mod file.

When I run the make command within Geany, I get the following error…

Undefined symbols for architecture x86_64
    "___dummy_routines_MOD_record_time", referenced from:
         _MAIN__ in dummymain.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [dummymain] Error 1

I use the other modules in the same file without issue but this won’t work?!

I address this in the executing file by…

        use stellar_values, only: m_sun, yr, grav
        use dummy_routines
        implicit none

By default, module entities are public, but I often use a compiler option that sets them to private. Maybe you are too, in which case they need to be declared public. Below the line

module dummy_routines

can you add a line

public :: record_time

and try compiling again?

I tried this but it didn’t make any difference.

Thanks anyway. :slight_smile:

Just as a sanity check, are all of the *.o files included in the linking command? I.e.

gfortran -o my_executable my_program.o my_modules.o ...

That was mentioned to me before and I forgot to check!
Thank you. :slight_smile:

I suppose my one question is, why does the other use command work?

As you can see in the OP, I have a declaration of use stellar_values, only: m_sun, yr, grav, which works.
Now, in stellar_values there are only parameters; no subroutines. So, there is no contains declaration. Is this the reason for the difference?

If just named constants, there is no need for link-time references. Procedures, variables and initialized derived types will typically need external references.

1 Like

It is likely that the parameter values are being inlined, and thus do not need to be referenced by symbol (as explained by @sblionel), or it is possible that the linker has given up before trying to resolve these symbols, and thus does not know that they are also missing. The former is probably the more likely explanation in this case