Comments (4)
@matklad Released 0.6.0. Since removing the dependency involved a minor, but breaking nevertheless, change to the Library::get
behaviour, I had to make a minor (rather than patch) version bump. I ended up making a number of other breaking changes while I was at it, so porting to 0.6.0 may not be as trivial as just changing the version number, but hopefully not too extremely difficult. Changelog is here.
from rust_libloading.
My own memory of the issue is fairly dated now, so there may be errors in it, but the keyword here is modern. The reason I ended up unconditionally compiling this snippet for any unix is because I do not really want to spend time looking into which version of glibc introduced MT-safe dlerror, and then trying to figure out if those versions are at all relevant to anyone, anymore. And that’s the work I’d have to do just to stop doing this for glibc
targets. There are also musl, uclibc, macos (to which I don’t have direct access) etc.
As per this comment the relevant standards only began allowing (allowing here is the keyword) MT-safe dlerror in 2008. While that was 12 years ago at this point, it is very plausible that there are still environments which not only take advantage of "allow" in the new versions of the POSIX standard, but actually adhere to the "must be program-wide global" from the older versions of it.
If we made use of this snippet conditional, I fear that this code-path would end up bit-rotting to the point of not working anymore on the less used platforms.
Overall I’d prefer stabilization of the weak linkage in Rust so that this could be implemented without C and without sacrificing anything else, But if C is a problem I’m open to try alternative approaches too.
from rust_libloading.
so that this could be implemented without C and without sacrificing anything else
I think using weak linkage here would be a perfect work-around, rather than a perfect solution. Like, on those platform where dlerror is MT-safe the perfect solution is to just not do anything on top. I however totally understand the perspective that, if work-around is not tested in the common case, it won't work in the edge case.
But if C is a problem I’m open to try alternative approaches too.
It is a minor problem, we can either remove our deny_c hack, or just use a fork of libloading (rust-analyzer is a binary, so we don't need to worry about several versions of libloading at all).
Still, my understanding here is that the problem this tries to solve is a niche of a niche (several version of libloading on an old platform), the solution is very elaborate, and that it's not 100% full-proof either (as the user can call dlerror/dlopen directly themselves, bypassing the check). I definitely don't have full context here, but my gut feeling that just documenting
Note that on some old platforms dl* family of functions is not thread-safe, and libloading might mysteriously break if you call those functions direcly, or if some other library does that. Note that some other library might include an earlier version of libloading.
might be a good enough solution. This can further be strengthened by yanking old major versions of libloading.
from rust_libloading.
Yeah, documenting the caveat is probably a good alternative too.
from rust_libloading.
Related Issues (20)
- Not working with wasm HOT 1
- cant find native static library 'global_static' HOT 1
- use once_cell trouble
- Relative path doesn't seem to work on Linux HOT 3
- Question: Is it possible to inject functions into libraries dynamically? HOT 1
- How to add a dll search folder ? HOT 2
- Sorry for the issues, is the unic way to comunicate with you
- Linking against musl fails HOT 2
- Old version of dynamic library crate used unless filename/location of crate changed. HOT 2
- Show OS error in the Display impl on Windows HOT 4
- Problems during cross-compilation HOT 1
- Library is cached if loaded multiple times HOT 1
- Loading dynamic library from memory HOT 1
- The specified program cannot be found HOT 4
- load a dynamic library crash HOT 1
- Support load main process symbol when share library path is null HOT 1
- Reflective loading? HOT 3
- Loading multiple independent instances the same library? HOT 1
- How do you obtain a static symbol from the original program image? HOT 2
- Thread-local RefCell containing heap-allocated object produces unexpected library re-loading behavior HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust_libloading.