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

Include deduced locations for native libraries in rpath #2397

Closed
catamorphism opened this issue May 17, 2012 · 4 comments
Closed

Include deduced locations for native libraries in rpath #2397

catamorphism opened this issue May 17, 2012 · 4 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@catamorphism
Copy link
Contributor

From a FIXME in back::link:

    // FIXME: At some point we want to rpath our guesses as to where
    // native libraries might live, based on the addl_lib_search_paths
@thestinger
Copy link
Contributor

This is really not something that should be done, installed libraries will already be in the search path. Using rpath is very fragile and won't survive changes to the system configuration.

@mzabaluev
Copy link
Contributor

A particular problem here is native libraries that are part of the build. See here and here for an example: not only do I have to use -L and LD_LIBRARY_PATH for a library that the test crate should have no logical visibility for, I have to also explicitly bring it in as an external module.

Of course I could choose to build an install the tiny support library as a separate project, but it's annoying to have to do this. In the C land, we've long had libtool and similar solutions to take care of it.

@graydon
Copy link
Contributor

graydon commented Apr 30, 2013

closing as we have strong feedback that rpath is undesirable; we can approach along other avenues (static linking + use of workspace lib paths)

@jonhoo
Copy link
Contributor

jonhoo commented Dec 17, 2021

Given that rpath is a configurable parameter these days, and defaults to off, I wonder if this should be re-visited. If the user specifically opts into RPATH with -Crpath=y, it will probably be surprising to discover that only some of the paths that linked libraries were pulled from got written into the RPATH. It certainly surprised me 😅 In my case, I had to pass the paths already passed with -Clink-arg=-L through additional -Wl,rpath arguments through -Clink-arg= in rustflags to get things to work, which seems unfortunate. Though it could also be something the Rust compiler can't easily extract, I'm not sure?

Regardless of the decision ultimately made here, I think the nuances of this behavior should be documented in the -Crpath docs.

Just for reference, the mentioned FIXME now lives here:

// FIXME (#2397): At some point we want to rpath our guesses as to
// where extern libraries might live, based on the
// add_lib_search_paths

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
only do env var cleanup if all threads have stopped

Hopefully fixes rust-lang/miri#2396
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

5 participants