The build scripts add a RUNPATH entry in the installed library. It may be a good idea to leave the RUNPATH empty so that the linking fails in incorrectly initialized environments, instead of linking with incorrect libraries.
The default behavior of CMake is to remove RUNPATHs during DSO installation with the expectation that the executable linked with the DSO is usually responsible for providing the RPATH/RUNPATH. A hard coded path can cause issues if the library is used in a different environment from the one it was built.
For instance, I am building the MUMPS library in an HPC system, with a few development modules loaded. With the modules loaded, the shared object dependencies are resolved correctly:
The dependency on libbz2 (which is introduced by scotch) can no longer be resolved, and more importantly, the loaded FORTRAN library does not support the required version, in the 1st line of the ldd output.
The MUMPS library is provided through a module that sets up the environment, so that users do not have to load whole development modules. Executables that use MUMPS may also have a few paths hard-coded in their RUNPATH.
I believe it would be nicer if the library failed to detect the required DSOs completely when the environment is not set up properly, instead of detecting incorrect DSOs and possibly crashing at runtime. Would it make sense to maintain the default CMake behavior, removing the RPATH from the installed library, and leave it as an option for the user to choose otherwise?
The relevant settings are in file cmake/compilers.cmake:
The build scripts add a RUNPATH entry in the installed library. It may be a good idea to leave the RUNPATH empty so that the linking fails in incorrectly initialized environments, instead of linking with incorrect libraries.
The default behavior of CMake is to remove RUNPATHs during DSO installation with the expectation that the executable linked with the DSO is usually responsible for providing the RPATH/RUNPATH. A hard coded path can cause issues if the library is used in a different environment from the one it was built.
For instance, I am building the MUMPS library in an HPC system, with a few development modules loaded. With the modules loaded, the shared object dependencies are resolved correctly:
However, after removing the development modules, there are issues in resolving the shared object dependencies:
The dependency on
libbz2
(which is introduced by scotch) can no longer be resolved, and more importantly, the loaded FORTRAN library does not support the required version, in the 1st line of theldd
output.The MUMPS library is provided through a module that sets up the environment, so that users do not have to load whole development modules. Executables that use MUMPS may also have a few paths hard-coded in their RUNPATH.
I believe it would be nicer if the library failed to detect the required DSOs completely when the environment is not set up properly, instead of detecting incorrect DSOs and possibly crashing at runtime. Would it make sense to maintain the default CMake behavior, removing the RPATH from the installed library, and leave it as an option for the user to choose otherwise?
The relevant settings are in file
cmake/compilers.cmake
: