search

nagisa / rust_libloading

Bindings around the platform's dynamic library loading primitives with greatly improved memory safety.
https://docs.rs/libloading
ISC License
1.21k stars 99 forks source link

Fails to build with the `asmjs-unknown-emscripten` target #23

Open yoanlcq opened 7 years ago

yoanlcq commented 7 years ago

cargo build --target asmjs-unknown-emscripten gave me the following output :

   Compiling libloading v0.3.4
error: failed to run custom build command for `libloading v0.3.4`
process didn't exit successfully: `/home/yoon/git/trust/fate-rs/target/debug/build/libloading-b2c9bb378ef0f558/build-script-build` (exit code: 252)
--- stderr
Building for an unknown target_os=`emscripten`!
Please report an issue 

Build failed, waiting for other jobs to finish...
error: build failed

Admittedly, loading dynamic libraries in Emscripten makes little to no sense, so this should be expected - I ran into this when trying to build my test project which depends on al-sys from alto. I'm wondering what the desired behavior would be here. My gut feeling is that libloading should still compile, but produce no-ops, but on the other hand, the actual fix would probably to set libloading as an optional dependency of al-sys.

nagisa commented 7 years ago

https://github.com/kripken/emscripten/wiki/Linking

Seems to suggest that there exists a dlopen uh… fallback(?)… in emscripten. I will gladly merge a PR that implements loading for emscripten.

yoanlcq commented 7 years ago

Interesting! I'd have looked into it, but I lack both time (currently) and expertise (in Rust and Emscripten), was just hacking around. (About Alto, seems like OpenAL works out-of-the-box on Emscripten, so I should also reach out to them.)

nagisa commented 6 years ago

I’m not too interested in supporting emscripten target at this point. WASM backend is likely to replace the emscripten target in near future.

GabrielMajeri commented 6 years ago

@nagisa Even if we ignore Emscripten, WebAssembly does support dynamic linking between modules using dlopen / dlsym (no dlclose though).

Should we close this issue and open a new one for WASM or keep this one and rename it?

nagisa commented 6 years ago

I meant my comment to imply that wasm support is interesting to me. It would need more work as implementing dlopen/dlsym would be necessary (the functions are not provided).

Dlclose not being implementable doesn't seem like much of a problem.

On Jan 3, 2018 7:58 AM, "Gabriel Majeri" notifications@github.com wrote:

@nagisa https://github.com/nagisa Even if we ignore Emscripten, WebAssembly does support dynamic linking http://webassembly.org/docs/dynamic-linking/ between modules using dlopen / dlsym (no dlclose though).

Should we close this issue and open a new one for WASM or keep this one and rename it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nagisa/rust_libloading/issues/23#issuecomment-354942169, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0ijiu9edoo7QhVDSbnMaG-f3dBfzks5tGxcFgaJpZM4Mvn3v .

chayleaf commented 3 years ago

WASM backend is likely to replace the emscripten target in near future

wasm32-unknown-unknown doesn't support C interop, so it still has a very real use case