RPATH incorrect when clang links a library compiled with gfortran

Mark Cianciosa
Tue, 25 Oct 2022 20:17:11 +0000
Code

I’m running into a runtime problem that I have never had before. I have a bunch of projects spread out across multiple GitHub repositories. A parent repository collects coordinates all this using a bunch of FetchContent commands. In one subproject I define a library target that C and Fortran sources and links against all bunch of library dependencies. In a different repository, I have a target executable that contains C++ sources which links against the first library. Everything configures and builds fine but when I run it, I get a runtime error that gfortran runtime libraries were not found.

dyld[85850]: Library not loaded: '@rpath/libgfortran.5.dylib'
  Referenced from: '/Users/m4c/Projects/Stellarator-Tools/build/_deps/siesta-build/xsiesta_test'
  Reason: tried: '/usr/local/lib/libgfortran.5.dylib' (no such file), '/usr/local/lib/libgfortran.5.dylib' (no such file), '/usr/local/lib/libgfortran.5.dylib' (no such file), '/usr/lib/libgfortran.5.dylib' (no such file)

It looks like my executable target doesn’t inherit anything about the RPATH from my library target. I installed gfortran using the prebuilt binaries which installs gfortran in /usr/local/gfortran/lib so it gets missed by the default lookup paths.

When I have an executable target that contains fortran sources, everything works fine. I think in these cases, gfortran is doing the linking so it’s setting the appropriate search paths in the binary. So how can I get my C++ executable target to link the gfortran runtime library at runtime correctly? Should I manually set the RPATH by reading the property from the library target, or would it be better to just include a dummy fortran source in the executable target?

The codes in question are open source here:
The CMakeLists.txt where I create the library target.
The CmakeLists.txt where I create the target executable and link against the library target.

2 posts - 2 participants