perl issue - rpath vs ld_library_path

[hiker]

I've been trying to create a non-container environment on NCI (to help me/the devs to debug a tau build issue in our container). So I used the aws setup. After some work, I got problems when spack compiler perl:

loadable library and perl binaries are mismatched (got handshake key 0xf380080, needed 0xcd00080)

(the handshake keys might have been different).

The reason is that spack uses rpath, and the rpath added on nci (/half-root/lib... something or other) contains some libs that are required, but this directory also contains a library for perl. So the newly compiled perl has an rpath to a directory that contains the old perl lib, which is not compatible.

The suggested solution from spack/spack#40848 was:

spack config add config:shared_linking:type:runpath`

This indicates that LD_LIBRARY_PATH should take precedence over rpath. This solved at least this issue for me.

I am wondering (and hence opening a ticket, given that my approach of using aws scripts on nci is rather unusual ;) ) if this should either be documented (as useful info for other sites), or if we should consider using this in general? I can't judge the impact (and am equally happy to just get this ticket closed with 'too esoteric' as reason :) )

[lucaparisi91]

We had a similar issue on Archer2. I think we fixed that by adding the system available perl as an external package. Spack adds library information to rpath because they cannot be overridden. Running is more reproducible, because they do not depend on the environment and that is the behaviour I would normally expect from spack. Modifying the perl package so that is prepends the right rpath or links differently from all other libraries might be an option. An alternative is to use a compiler that does not add the extra paths ( might not always be possible )