RPATH-linking can hide runtime dependencies

[ocaisa]

In easybuilders/easybuild-easyconfigs#25259 there is an example where a runtime dependency slipped through as a build dependency only for libarchive. The RPATH linking meant that the library is always found, but with our RPATH wrappers this can lead to link time problems later when libarchive itself is used as a dependency (since the build dep libary is not available via LIBRARY_PATH linking will fail).

The RPATH checking we do should probably be quite strict, and if it finds a library which matches the EBROOTXXX of a build dependency it should complain. We need a switch to disable this though, we use this loophole in EESSI to make CUDA a build time dep, and only rely on the runtime libraries for executables that we ship directly.

[akesandgren]

It should probably also complain it if finds one that isn't directly listed in either builddeps or deps, since then it is unclear where it really comes from.
I.e. if a builddep brings in something that is actually a dep, but it isn't listed as a dep....

I.e. check the env for all EBROOT... vars and check rpath linking

[Thyre]

We've noticed that a few times already at JSC, as we're still not using rpath, hence require having proper dependencies.
Here's another example: easybuilders/easybuild-easyconfigs#24406

That's certainly one of the large drawbacks of only testing rpath builds with jsc-zen3. I've missed switching some of my test systems away from rpath in recent toolchains, but probably will do that partially for 2026+.

Having a stricter check to at least question if picking up system paths or something from another module is intended sounds like a good idea. Both can happen easily, and sneakily break the same version later on, or future versions due to module changes in the dependency chain.

[ocaisa]

Thinking about how to implement this, we would need to gather EBROOT* from the build time environment, then make a whitelist based on the listed dependencies. During the rpath check, anything that matches an EBROOT* but is not in the whitelist gets flagged as a missing runtime dependency.

Edit: No, that is too strict. We need to check only the first level of lddtree (direct deps only).

[ocaisa]

Another example in easybuilders/easybuild-easyconfigs#25285