rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
96.78k stars 12.5k forks source link

DynamicLibrary::prepend_search_path not very useful on Linux #16901

Closed tomjakubowski closed 7 years ago

tomjakubowski commented 10 years ago

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 commented 10 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.

pnkfelix commented 10 years ago

(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 commented 9 years ago

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 commented 7 years ago

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

sfackler commented 7 years ago

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