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

DynamicLibrary::prepend_search_path not very useful on Linux #16901

Closed
tomjakubowski opened this issue Aug 31, 2014 · 5 comments
Closed

DynamicLibrary::prepend_search_path not very useful on Linux #16901

tomjakubowski opened this issue Aug 31, 2014 · 5 comments

Comments

@tomjakubowski
Copy link
Contributor

From the dlopen(3) man page:

  • If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain a colon-separated list of directories, then these are searched. (As a security measure this variable is ignored for set-user-ID and set-group-ID programs.)

My reading of this is that changes to LD_LIBRARY_PATH made while the program is running do not affect the search path. This also seems to be the case in practice when using DynamicLibrary on my Linux machine.

@tomjakubowski
Copy link
Contributor Author

If I'm right there isn't much that can be done to fix this other than add a caveat to the docs. I don't know what the behavior is like on other platforms, and I can't find a test which exercises this function, but it appears rustc uses this feature on Windows.

@huonw huonw added the A-libs label Aug 31, 2014
@pnkfelix
Copy link
Member

pnkfelix commented Sep 1, 2014

(we could attempt to re-implement the search behavior of dlopen in rust code itself in order to find the library and then feed that as an absolute path to our call to dlopen itself, right? But that sounds pretty nasty and error-prone.)

@davvid
Copy link

davvid commented May 21, 2015

If this function is intended for users then implementing the dlopen logic would be helpful because, yes, changing LD_LIBRARY_PATH after program startup has no effect on Linux, and ditto DYLD_LIBRARY_PATH on Darwin.

But DynamicLibrary::prepend_search_path() would not be a good API because it's a global static function. A more useful API would be a non-static struct, e.g. DynamicLibraryLoader, which can be instantiated in user code.

The benefit is that it would allow users to create instances with differing search paths. An instance of a DynamicLibraryLoader could have an add_search_path() that actually works because it would implement the search-path logic itself. I wouldn't call it nasty or error-prone; the logic is pretty simple.

At first I thought that DynamicLibrary::search_path() could be consulted when constructing a DynamicLibraryLoader's initial search path, breathing a little more life into DynamicLibrary's utility. In that world the global prepend_to_search_path() would serve a useful purpose -- it can be used to setup the default search path that's present when creating new instances. But, thinking it through, global state is bad, and coupling these two structs would also be a bad idea, so, yeah, prepend_search_path() is kind of a useless API and should probably be documented as having caveats on most non-Windows platforms.

@apasel422
Copy link
Contributor

Is this actually a libs issue? It appears that prepend_search_path is defined in librustc_back.

@sfackler
Copy link
Member

It used to live in libextra. Closing, since this is no longer publicly exposed.

bors added a commit to rust-lang-ci/rust that referenced this issue Mar 31, 2024
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

6 participants