-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Comments
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. |
(we could attempt to re-implement the search behavior of |
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. |
Is this actually a libs issue? It appears that |
It used to live in libextra. Closing, since this is no longer publicly exposed. |
fix: Revert debug extension priorities Close rust-lang#16901
From the dlopen(3) man page:
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 usingDynamicLibrary
on my Linux machine.The text was updated successfully, but these errors were encountered: