Tracking issue for std::dynamic_lib

[alexcrichton]

This is a tracking issue for the unstable dynamic_lib feature of the standard library. This module should probably just be made private to the standard library and the compiler rather than being exported for now. A future RFC could decide whether it should be a module in the standard library or not.

[nagisa]

dlopen bindings in some form is a very useful thing to have, but I personally care little whether it is stabilised in stdlib or moved out into an external crate.

[alexcrichton]

Yeah if we remove from the standard library I'd definitely at least want an external crate with this functionality. That being said the standard library does indeed use this as an implementation detail for various aspects, so that may be a good indicator that it should be in libstd to begin with.

[nagisa]

I so far found a several problems with the API exposed currently:

Some of the exposed methods are not cross-platform or might not do what’s intended. Most notably the methods dealing with search pathes… On Windows it doesn’t use AddDllDirectory/SetDllDirectory and manipulates environment instead. Man pages claim that on unix LD_LIBRARY_PATH may not be accounted for in some reasons and as far as I interpret the text (didn’t test, though) only the value of the variable as it was during process initialisation is used.

dlsym returns *mut void, and GetProcAddress returns FARPROC. *mut void is a regular pointer and FARPROC is a function pointer. While POSIX-compiliance requires *mut T and function pointers be interchangeable, I couldn’t find anything of a sort for Windows. That is, on POSIX-compiliant systems you can dlsym functions and statics and whatnot, while on Windows only function pointers can be safely retrieved.

Publicly exposed create_path and envvar methods make no sense. Instead of &Path, P: AsRef<Path> should be taken and symbols are not utf-8 therefore &str in symbol is a no-go.

Finally, I feel like there should be a simple way to prevent using symbols after the library is dropped, by e.g. returning &'library mut T? I’m experimenting with that.

[durka]

FWIW there is a crate which is just a copy of the unstable API from libstd, and if the crates.io download count is to be believed it has rather widespread usage.

[sfackler]

It seems like we should probably be deprecating and removing the in-tree version of this. The API's pretty bad right now and improvements should probably be prototyped out of tree.

[nagisa]

I’m experimenting with various options on my free time: libloading

[alexcrichton]

This issue is now entering its cycle-long FCP for deprecation in 1.5

[diwic]

There is also the shared_library crate.

Would be good to offer an recommended alternative in the compiler message.

[durka]

Really seems like a systems language should have this in std. (I realize we
need to experiment to find the right API.)
On Sep 25, 2015 3:28 AM, "diwic" notifications@github.com wrote:

There is also the shared_library https://crates.io/crates/shared_library
crate.

Would be good to offer an recommended alternative in the compiler message.

—
Reply to this email directly or view it on GitHub
#27810 (comment).

[retep998]

While POSIX-compiliance requires *mut T and function pointers be interchangeable, I couldn’t find anything of a sort for Windows. That is, on POSIX-compiliant systems you can dlsym functions and statics and whatnot, while on Windows only function pointers can be safely retrieved.

For Win32 and Win64, all normal pointers are interchangeable, so both function and data pointers can be retrieved fine. Far and near only mattered in the times of Win16.

[alexcrichton]

The libs team discussed this today and the decision was to deprecate.

[perlun]

For reference - std::dynamic_lib seems to be officially gone now; at least, its documentation which was originally available here is gone. Just for the sake of completeness, does anyone know in which Rust version it was dropped? (Or if it isn't, where are the docs now?)

[sfackler]

It was deprecated in 1.5.