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

[yoanlcq]

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]

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]

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]

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]

@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]

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" [email protected] 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]

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