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

Incorrect library load paths due to rpath patcher run on symlinks #5179

Closed
Tracked by #5134
mbargull opened this issue Feb 12, 2024 · 4 comments · Fixed by #5181
Closed
Tracked by #5134

Incorrect library load paths due to rpath patcher run on symlinks #5179

mbargull opened this issue Feb 12, 2024 · 4 comments · Fixed by #5181
Assignees
Labels
in-progress issue is actively being worked on locked [bot] locked due to inactivity severity::1 blocker; broken functionality with no workaround source::contributor created by a frequent contributor type::bug describes erroneous operation, use severity::* to classify the type

Comments

@mbargull
Copy link
Member

mbargull commented Feb 12, 2024

What happened?

In conda-build>=3.28.0, 1dc2470 replaced .os_utils.pyldd.is_codefile/.os_utils.*.codefile_type by direct calls to .os_utils.*.codefile_class which those functions wrapped.
For is_codefile/codefile_type the skip_symlinks parameter defaults to True whereas it is False for codefile_class which induced some unintended changes.
Notably, .post.post_process_shared_lib runs the rpath patcher on symlinks in conda-build>=3.28, which leads to invalid entries being set for the symlink targets in case the symlinks are located in different directories.

Case analysis at conda-forge/openmpi-feedstock#142 (comment) ff.
In that specific case, we have a lib/<target> and lib/<subfolder>/<symlink> -> lib/<target> for which lib/<target> gets rpath set to $ORIGIN/..:$ORIGIN/. instead of $ORIGIN/..:$ORIGIN/. if the symlink is processed after the actual target.
The issue was noticed because we ran into an bug with in patchelf which I could pinpoint to being introduced in NixOS/patchelf@42394e8 (i.e., affecting patchelf>=0.17.0.
(Others have run into issues introduced with that change; see NixOS/patchelf#446 ).


Test and patch incoming.

@mbargull mbargull added type::bug describes erroneous operation, use severity::* to classify the type source::contributor created by a frequent contributor labels Feb 12, 2024
@github-project-automation github-project-automation bot moved this to 🆕 New in 🧭 Planning Feb 12, 2024
@mbargull mbargull self-assigned this Feb 12, 2024
@kenodegard kenodegard moved this from 🆕 New to 👀 In Review in 🧭 Planning Feb 13, 2024
@kenodegard kenodegard added severity::1 blocker; broken functionality with no workaround in-progress issue is actively being worked on labels Feb 13, 2024
@h-vetinari
Copy link
Contributor

We ran into an apparent rpath problem when building boost with conda-build 3.28, which went away with conda-build 3.27. I cannot guarantee that it's the same bug, but it sounds related, and it would be good to verify/test that #5181 also fixes that issue.

@kenodegard kenodegard linked a pull request Feb 13, 2024 that will close this issue
2 tasks
@kenodegard kenodegard mentioned this issue Feb 13, 2024
43 tasks
@mbargull
Copy link
Member Author

@h-vetinari, hm.. libboost doesn't have these subfolder issues since it's all flat in lib/.
This might be another bug :/ ...
Let me try if I can somewhat quickly find which change might've caused that issue.

@mbargull
Copy link
Member Author

@h-vetinari, hm.. libboost doesn't have these subfolder issues since it's all flat in lib/. This might be another bug :/ ... Let me try if I can somewhat quickly find which change might've caused that issue.

For some reason this started to fail for me after the change from gh-5031 ...

@kenodegard
Copy link
Contributor

Resolved in #5181, upcoming conda-build 24.1.2 patch release will include the fix

@github-project-automation github-project-automation bot moved this from 👀 In Review to 🏁 Done in 🧭 Planning Feb 14, 2024
@github-actions github-actions bot added the locked [bot] locked due to inactivity label Aug 20, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
in-progress issue is actively being worked on locked [bot] locked due to inactivity severity::1 blocker; broken functionality with no workaround source::contributor created by a frequent contributor type::bug describes erroneous operation, use severity::* to classify the type
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants