Concurrency bugs caused by multiple linked-in versions of libloading

[nagisa]

It is possible for multiple versions of libloading to be linked into a binary. In that case static mutexes, such as one used to guard uses of dlerror have no effect.

[nagisa]

Having a separate version 0.1 crate that contains a mutex shared by all versions of libloading would help here. Maybe there is a better solution?

[GabrielMajeri]

Perhaps we should be inspired by the log crate? I've done a simple test and using different versions of the log crate and it works without any issue.

And their locks are simple AtomicUsizes in the main crate, no workarounds used. Perhaps Rust automatically handles static variables from different versions of the crate?

[nagisa]

I see nothing in log crate which would be resistant to this issue – namely, it seems to me that it would be trivial to have two different global loggers set up in a binary that links to two different versions of log crates.

In log case, though, all that would happen is two distinct loggers at the same time which is nothing too serious.

[jethrogb]

Why don't you use the links key in Cargo.toml? That was specifically designed to avoid issues where multiple crate versions link to the same native library. https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key

[nagisa]

There quite a few reasons that make using links inappropriate in this case:

1. There isn’t always a logical "library" to specify there. For example on linux dl* family of functions are provided by libc rather than a separate library. We could specify a dummy value of some sort, but that would still not prevent the same sort of issues from occurring if two distinct crates using similar functions are linked in, or this crate is used in a larger project that uses dl* functions independently...
2. This issue is not relevant to most of the targets at all. Most of the targets have implemented dlerror in a thread-safe manner and e.g. Windows does not have this problem in the first place. Why would I strive to prevent users from doing valid things only to maintain safety for some obscure platform that implements an old version of the POSIX standard (or has a non-thread-safe dlerror)?
3. Experience with other crates has been that links is an anti-pattern, especially with system libraries. winapi specifically had to go through a fairly painful version bump in the past after it has been found that links is not appropriate to it.

[jethrogb]

1. There isn’t always a logical "library" to specify there. For example on linux dl* family of functions are provided by libc rather than a separate library. We could specify a dummy value of some sort, but that would still not prevent the same sort of issues from occurring if two distinct crates using similar functions are linked in, or this crate is used in a larger project that uses dl* functions independently...
2. This issue is not relevant to most of the targets at all. Most of the targets have implemented dlerror in a thread-safe manner and e.g. Windows does not have this problem in the first place. Why would I strive to prevent users from doing valid things only to maintain safety for some obscure platform that implements an old version of the POSIX standard (or has a non-thread-safe dlerror)?

The way to do this would be to create a separate dl-sys crate with the appropriate functions and links = ["dl"]. This crate could then optionally depend on that crate (with target-specific dependencies).

3. Experience with other crates has been that links is an anti-pattern, especially with system libraries. winapi specifically had to go through a fairly painful version bump in the past after it has been found that links is not appropriate to it.

I see. This sounds like more of a concern. I tried to find more info on this, but couldn't really find anything. Is there a cargo issue discussing this?

[nagisa]

The way to do this would be to create a separate dl-sys crate with the appropriate functions and links = ["dl"]. This crate could then optionally depend on that crate (with target-specific dependencies).

It still successfully prevents valid use-cases on platforms that do implement the dl API, but in a MT-safe manner (which is most of them). Either way, I strongly prefer the solution that I ended up implementing for this library. It is technically superior and has better UX compared to links in about every way.

The only downside is that currently it requires a C compiler to stay in stable-land. Need for the C compiler can be removed later once the linkage attribute is stabilized in rustc.

I see. This sounds like more of a concern. I tried to find more info on this, but couldn't really find anything. Is there a cargo issue discussing this?

There is likely no cargo issue about this. There is retep998/winapi-rs#238 related to this, though.