Closed tomjakubowski closed 7 years ago
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 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.)
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 prepend_search_path
is defined in librustc_back
.
It used to live in libextra. Closing, since this is no longer publicly exposed.
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.