0

We have a quite large Fortran program that's developed and builded using Visual Studio and Ifort for Windows. On the linux side, we used to get the .dep generated on windows side, proccess it using a script, and create a command line call with the files on the order needed for the compilation. Now, I'm trying to rewrite the linux build using CMake.

After many solved problems (casing, enconding, ...) I've encountered some errors on the linking part. We have some subroutines defined on separated files that get called straight from other files like: CALL SUBROUTINE_NAME ()

I guess VisualStudio is somehow handling this linking but when I try to compile it using CMake on linux i get an error "undefined reference to SUBROUTINE_NAME".

My first tought was trying to include the file where this routine is defined but the subroutines are defined on multiple directories and, as far I understand, unless I put all this places on the include path for the compiler they can't be found.

Another option would be rewriting all this as modules and using them where needed. I guess this would be a cleaner solution but also a lot of work that I'm not sure I'd have the time for now.

First of all, I'd like to make sure my reasoning seems right and then what would be the best or some alternatives way to deal with this, like a way to manually include the paths for each occurrence or if there's a way to make CMake work like VisualStudio and resolve this references for example.

Thanks in advance for any insight and don't hesitate to get in touch and ask for more information if needed.

Edit to add more CMake info as requested:

CMakeLists.txt:

file(GLOB_RECURSE sources ./src/*.for)
add_executable(program_name ${sources}

target_include_directories(program_name PUBLIC "./src/includes")

I've managed to manually compile the file passing the .o of the separated subroutine but couldn't get CMake to include it as needed.

My subroutine file is been processed by CMake and a .o file is been generated for it, as I'm passing it as source.

Whenever I use a module, CMake can automatically add the module as a dependency for the file. But on this cases, where I'm calling the subroutine directly it doesn't generate the correct dependency for the Makefile.

jmiguel
  • 349
  • 1
  • 9
  • 1
    Can you give concrete examples of the errors you are getting? And is it safe to assume you are using `gcc` on Linux? – TallChuck Mar 11 '22 at 05:12
  • [this question](https://stackoverflow.com/questions/66855252/what-is-an-undefined-reference-unresolved-external-symbol-error-and-how-do-i-fix) might help. Also, "rewriting all this as modules and using them where needed" is almost always the right solution for any project with more than one file. – veryreverie Mar 11 '22 at 09:17
  • How are your `CMakeLists.txt` file(s) structured? Is `SUBROUTINE_NAME` in a different library to whatever it is that's trying to call `SUBROUTINE_NAME`? If so, I'd suggest looking into `target_link_libraries` and `add_dependencies`. – veryreverie Mar 11 '22 at 09:19
  • @veryreverie I've updated the question with the `CMakeLists` sourcing logic, details and some updates. – jmiguel Mar 11 '22 at 16:43
  • @TallChuck I'm actually using `ifort` but I guess my problem is actually on the CMake side rather the compiler (I've manage to manually compile it passing the correct .o file as a dependency) – jmiguel Mar 11 '22 at 16:44
  • is `SUBROUTINE_NAME` in `./src/` or `./src/includes`? – veryreverie Mar 11 '22 at 23:18
  • @veryreverie yes, it is in `./src/`. The `SUBROUTINE_NAME` is actually getting compiled into a `.o` by CMake – jmiguel Mar 13 '22 at 23:54
  • I suppose I solved my problems: some more inconsistent casing when changing to case sensitive linux's filesystem – jmiguel Mar 14 '22 at 00:52

0 Answers0