Link against wasmedge static library

[jprendes]

This PR links the wasmedge shims agains the wasmedge static library:

• This simplifies distribution of the shims.

It uses the (new) combination of standalone and static features of the wasmedge-sys crate, which automatically downloads the static library as part of the build process:

• This removes the need to manually install wasmedge.
• Simplifies dependency management: the wasmedge version is now set by the upstream wasmedge-sdk crate.
• This requires switching to a git commit for wasmedge-sdk until tag 0.10.0 is released.

[rumpl]

Beautiful

[CaptainVincent]

Great work! This greatly improves the user's installation experience,
and everything in my tests turned out fine, too. 👍

[cpuguy83]

Doesn't seem like we should need wget?

[jprendes]

wasmedge-sys needs wget to download the library.
We could fix that upstream for the next release of wasmedge-sdk and remove it then.
WasmEdge/wasmedge-rust-sdk#30

[jprendes]

I've removed these two lines from here.
I don't know what was the original motivation, but the CI check succeeded.

@defims : what was the motivation for these lines? am I missing something?

[jprendes]

wasmedge-sys needs wget to download the library.
We could fix that upstream for the next release of wasmedge-sdk and remove it then.
WasmEdge/wasmedge-rust-sdk#30

[cpuguy83]

This looks great, if there's a change that's needed for the containerd config.toml stuff we can follow-up.

[ipuustin]

I'm bit on the fence with this one... I really like that we now automatically have the right version of the WasmEdge library. However I think downloading things with custom methods during the build has some issues, such as the possibility of having difficult-to-debug issues when building in a proxy prison or other not-fully-networked environments. It also makes it more difficult to have SBOMs and reproducible builds, because we have no way of knowing what exactly has been downloaded (for example -- is a WasmEdge library security fix part of a built shim or not?).

An optimal case might be to have an option to pre-download the library, or at least specify which library checksum we are expecting during the build?

[jprendes]

@ipuustin , would you mind creating an issue in the wasmedge-rust-stk repo to add this functionality?

I was looking here at how the dbus crate does it. But I'm not sure that's directly applicable to this case.

[cpuguy83]

Apologies I clearly made a mistake here with regard to automatic downloading stuff.
Ideally this would not download anything at all and use the system libs.
The lib should be a build-time dep that needs to be handled by the builder not our makefile, build.rs, or whatever from dependencies.

We can certainly create a script to install deps that someone who's building can choose to run or not.

Also probably static compilation should be behind a crate feature.

[jprendes]

I agree with making static buils a crate feature. That woud allow reverting to the previous behavior.
I am neutral to having it as a default feature or not.

How exactly the vendoring happens, I think that would be better discussed as an issue in libwasmedge-rust-sdk.
I've been looking around, and most crates vendor libraries by adding the upstream source as a git submodule, and then using cc to build it. I guess that could be a vendor feature for libwasmedge-rust-sdk, while standalone keeps the download behavior.