This one is getting me crazy. Consider the following tree structure:

├── app
│   └── CMakeLists.txt
├── lib
│   ├── bindings
│   │   ├── CMakeLists.txt
│   │   └── fortran
│   │       └── CMakeLists.txt
│   ├── CMakeLists.txt
│   └── src
│       ├── CMakeLists.txt
│       ├── core
│       │   ├── CMakeLists.txt
│       └── include
│           ├── CMakeLists.txt
├── CMakeLists.txt

where:

# Top level CMakeLists.txt
project( project
   LANGUAGES C Fortran
)
add_subdirectory( lib )
add_subdirectory( app )

# lib/CMakeLists.txt
add_subdirectory( src )
add_subdirectory( bindings )

# lib/src/CMakeLists.txt
set( sources )
add_subdirectory( include )
add_subdirectory( core )
add_library( Lib STATIC ${sources} )

# lib/bindings/CMakeLists.txt
add_subdirectory( fortran )

# lib/bindings/fortran/CMakeLists.txt
add_library( LibF STATIC libf.F90 )
target_link_libraries( LibF PUBLIC Lib )

# app/CMakeLists.txt
add_executable( app app.F90 )
target_link_libraries( app PRIVATE LibF )

It consists of a main C static library (lib/src), a Fortran (interface module) static library (lib/bindings/fortran), and a Fortran application executable (app). When linking the app target, I am getting plenty of undefined references errors to the C-library symbols. The strange thing is that I made a toy reproducer with the exact same structure, to see if I was able to narrow down the issue, but there I do not have any issues, so I do not really understand what’s wrong in this case.

I even checked the last linking command

/usr/bin/gfortran CMakeFiles/app.dir/app.F90.o -o main  ../lib/bindings/fortran/LibF.a ../lib/src/Lib.a

which has the exact same order in the real case, which nonetheless fails..

How can I debug this further?