Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perl issue - rpath vs ld_library_path #12

Open
hiker opened this issue Dec 11, 2024 · 0 comments
Open

perl issue - rpath vs ld_library_path #12

hiker opened this issue Dec 11, 2024 · 0 comments

Comments

@hiker
Copy link
Collaborator

hiker commented Dec 11, 2024

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 :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant