File extension inconsistency

[mkroman]

Currently, as per the docs, on Windows, the default behavior for Library::open(…) is to automatically concatenate the platform-specific .dll extension when no extension is provided (or just omit it when a . suffix is given.)

This behavior is inconsistent across platforms, for example:

use libloading::Library;

fn main() {
    let library = Library::new("libzeta_core").unwrap();
}

On Windows, this will, as expected, try to load libzeta_core.dll - however, on Linux, this will try to load libzeta_core which is not the expected shared library filename - it's expected to be libzeta_core.so.

I'd suggest that libloading provides a platform-specific load sequence:

• If no extension is given, it should try to load the library with a platform-specific extension
• • On Linux, *BSD and macOS, this should be .so
• • On Windows, this should be .dll

In all cases, when a . suffix is given, it should just try to load the filename without any extension.

[nagisa]

How implementations of dynamic library loading search for a shared library is in general a very platform-specific thing and when the extension is applied or not for the user is part of that algorithm.

The documentation only reflects the behaviour of how the underlying system works (mostly noted so that users do not rely on this behaviour inadvertently). This library does not attempt to implement library search, instead recommending users to specify full or relative path to the library in the first place. This has multiple reasons:

• library search is a well known source of soundness and safety issues – if somebody places equally named library in one of the earlier paths system will search, wrong code may end up being loaded;
  • it is full of race conditions and override points;
  • for instance, when the extension is not supplied (argument to Library::open is X) and all of X and X.so and libX.so exist in the same directory (that otherwise would be considered to be in search path), which one should be chosen? What if not all of them are a file? Or have an executable bit?
  • Maybe it's the Windows behaviour that’s ill considered in the first place and UNIXes are doing it the right way?
• people may have come to expect some behaviours of the library search on their platform. Implementing a custom search algorithm would mean a breaking change and/or obscene amounts of work attempting to emulate and reverse-engineer the implementation for the dozens of current and future targets supported by this library.

My recommendation remains as it was in documentation: name the shared libraries in a predictable way across platforms (say library.module) and use either proper relative paths ./... or absolute paths to refer to those libraries in order to not engage library search algorithms.

All that said, I would be willing to accept a PR implementing a cross-platform-consistent and well documented library search in a separate function of this library. This would likely end up as fn(name: &str) -> Result<PathBuf, ?>.

[mkroman]

All very good points.

I think you're right, it's much better if it's left up to the user to implement a lookup function, and I also think that Windows is in the wrong here.

When reading the documentation I was a bit perplexed by the .module extension - I wasn't sure if it had any significant meaning or if it was just an example. This gave me the idea that maybe there could be an automatically expanded format syntax that was platform-specific

For example:

use libloading::Library;

fn main() {
    let library = Library::new("libzeta_core.%lib%").unwrap();
}

Or something of that description - possibly prettier - which, on UNIX-like platforms would expand to libzeta_core.so, on Windows, it would expand to libzeta_core.dll and on macOS I'm not really sure between .so and .dylib - I assume they can both be loaded with dlopen?

But it's just an idea, I'm equally in favor of keeping libloading as simple as possible.

[mainrs]

I think a better approach would probably be to include const that are platform dependent and check if the name ends in the one that the binary has been compiled for:

#[cfg(windows)]
const LIB_SUFFIX: &str = ".dll";

#[cfg(unix)]
const LIB_SUFFIX: &str = ".so";

// ...

fn prepare_name<'a>(name: &'a str) -> Cow<'a, str> {
    if !name.ends_with(LIB_SUFFIX) {
        Cow::Owned(format!("{}{}", name, LIB_SUFFIX))
    } else {
        Cow::Borrowed(name)
    }
}

Instead of introducing new constants you could just re-use the ones that Rust provides: https://doc.rust-lang.org/std/env/consts/index.html

This would also allow for prefix support.

Edit if there is interest I can upon a PR that does something similar to the function above. I could also take the DLL_PREFIX into account so people can omit i when opening a library like the original issue author showed.

[mainrs]

I've created a PR to resolve this issue. If someone wants to take a look and give feedback/criticism, go ahead :) Hopefully this is the behavior you've imagined @mkroman