https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86863
Zaak <zbeekman at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zbeekman at gmail dot com
--- Comment #2 from Zaak <zbeekman at gmail dot com> ---
It appears that `module procedure` can also cause a link-time error that will
get resolved when switching to `module subroutine`. I haven't dug into this too
much, but I get missing/unresolved symbols, but if I switch the implementation
to `module subroutine` then the unresolved symbols go away.
The linker errors look like:
Undefined symbols for architecture x86_64:
"___vtab_fgr_mesh_Fgr.5058", referenced from:
___timestep_MOD_store in Timestep_implementation.f90.o
"___vtab_grid_index_Fd_grid.5056", referenced from:
___timestep_MOD_store in Timestep_implementation.f90.o
"___vtab_material_type_Material.5041", referenced from:
___timestep_MOD_store in Timestep_implementation.f90.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
Changing `module procedure` to `module subroutine` and adding the interface
variables, variable declarations, etc. resolves this linker issue. So it seems
that the compiler generates code looking for the wrong symbols when `module
procedure` is used vs `module subroutine` inside of a submodule (maybe?)
I'm not entirely sure how to go about creating a minimally complete verifiable
example for this. Compilation was done with GFortran 8.2 (installed via
Homebrew) on macOS and the CMake based build system has the compiler drive the
linker, we don't call ld directly ourselves anywhere.
