install: also install liblucet_wasi

[thibaultcha]

The documentation on lucet-wasi specifies:

It can be used as a library to support WASI in another application, or as an executable, lucet-wasi

However, liblucet_wasi isn't available as a library in $LUCET_PREFIX/lib.

Is this an overlook?

[thibaultcha]

Similarly, I can't help but wonder how come the lucet.h, lucet_wasi.h, and other headers aren't installed in $LUCET_PREFIX/include?

[pchickey]

Hi, thanks for the bug report!

We don't use installed cdylibs in any of our tests, so this escaped our notice.

In fact, we don't recommend using the lucet-wasi cdylib alongside the lucet-runtime cdylib at all - some complications of how Rust dependencies get exposed in a cdylib makes this work incorrectly. Instead, if you need to use Lucet from C, we recommend using the approach that @shravanrn explains here: https://github.com/bytecodealliance/lucet/issues/441#issuecomment-612683535

I'll make changes to the repo and the docs to make that approach the canonical one, rather than hidden in a closed issue.

[thibaultcha]

@pchickey Thank you for sharing! Indeed, I believe that using Lucet from C will become a growing need as the WASI standard evolves and matures. In my opinion, many C "legacy" applications offering embedded scripting capabilities via languages such as Python, JS, Lua or other will see tremendous value in embedding a WASM sandbox such as Lucet instead. May I ask you to briefly elaborate on how the Lucet maintainers consider C embedding nowadays or in the future? What level of priority is given to this use-case (i.e. compared to Rust embedding)? Thank you.

[thibaultcha]

@pchickey It seems like liblucet_wasi is already configured to produce something similar to @shravanrn's "fullrt" lib: https://github.com/bytecodealliance/lucet/blob/master/lucet-wasi/Cargo.toml#L17-L21.

Debug builds on the current master branch seem to properly export all liblucet_runtime symbols from liblucet_wasi.so:

$ nm target/debug/liblucet_wasi.so | grep lucet_instance
5546:0000000000123a60 T lucet_instance_check_heap
5547:0000000000123c60 T lucet_instance_embed_ctx
5548:0000000000123a90 T lucet_instance_grow_heap
5549:00000000001239e0 T lucet_instance_heap
5550:0000000000123a20 T lucet_instance_heap_len
5551:00000000001239b0 T lucet_instance_release
5552:0000000000123930 T lucet_instance_reset
5553:0000000000123670 T lucet_instance_resume
5554:0000000000122d80 T lucet_instance_run
5555:0000000000123260 T lucet_instance_run_func_idx
5556:00000000001238b0 T lucet_instance_run_start
5557:0000000000123d30 T lucet_instance_set_fatal_handler
5558:0000000000123cc0 T lucet_instance_set_signal_handler
6984:000000000011c6d0 t _ZN13lucet_runtime5c_api18lucet_instance_run28_$u7b$$u7b$closure$u7d$$u7d$17h3fba84ee94c4a7bcE
...
$

However, release builds don't:

$ nm target/release/liblucet_wasi.so | grep lucet_instance
$

[pchickey]

May I ask you to briefly elaborate on how the Lucet maintainers consider C embedding nowadays or in the future? What level of priority is given to this use-case (i.e. compared to Rust embedding)? Thank you.

Lucet is fairly special-purpose compared to our sibling runtime Wasmtime (https://github.com/bytecodealliance/wasmtime), and shares many components. It uses the same code generator (Cranelift), different compilation strategy (AOT vs caching JIT), and caters to different priorities when implementing the runtime (Lucet leaves out a lot of features and is heavily optimized for low startup latency). We believe that most people probably just want to use Wasmtime, especially for a general-purpose embedding engine. The Wasmtime team has put a lot of time into providing a really good C API and there are already bindings to a number of languages available. Furthermore, in the long run (can't commit to timelines) we intend to merge Lucet into the Wasmtime project: https://www.fastly.com/blog/how-lucet-wasmtime-make-stronger-compiler-together.

If you do want to use Lucet over Wasmtime, we've been maintaining the C embedding with best effort, but we (the Lucet team at Fastly) don't use it anymore aside from the benchmark suite, so its not really on our radar. We're happy for help maintaining it, though, so I suppose if we can get the liblucet_wasi.so working the way you need, we can accept this PR. It will work unless you decide to expose any additional host functionality to wasm, in which case you'll need to follow the linked approach above.

However, release builds don't:

That is not the expected behavior. I'm not sure when that regression happened, but we did observe some changes to release mode linker garbage collection when we upgraded to rust 1.42.0.

[thibaultcha]

@pchickey Thanks for the details! I have been experimenting with various runtimes, and Lucet was high on my priority list due to the AOT compilation strategy. I will be giving Wasmtime a try as well, also in the context of embedding into a larger C application, so see you there maybe? Having both projects merge sounds exciting, and potentially less work on my end to have to support multiple runtimes/compilation strategies :clap:

Feel free to close this PR as your convenience - or ping me if it is worthy of a merge but needs some changes.

Best,

[pchickey]

Thanks!