Linux: Missing SONAME in "libwasmtime.so" hinders usage in CMake

[MartinKolbAtWork]

The shared library libwasmtime.so does not have an SONAME specified. This can be checked using this command:
objdump -p libwasmtime.so | grep SONAME

When libwasmtime.so is consumed in CMake, the linker produces a wrong output file due to the missing SONAME.
There is a workaround for this in CMake, but according to a reply from the CMake folks, the missing SONAME is a bug that must be fixed by the library provider (note: the CMake ticket refers to wasmer, but wasmtime has exactly the same issue, due to the Rust heritage):
https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562
“The .so file should have a SONAME. If it doesn't, that's a bug in the package”

I know that the problem is inherent for all Rust builds of cdylibs: rust-lang/cargo#5045
The Rust community did not fix this since 2018 (see issue above), but fortunately it’s easy to fix for library creators. You just need to put the following code into the build.rs of the library:

if cfg!(target_os = "linux") {
    println!("cargo:rustc-cdylib-link-arg=-Wl,-soname,libwasmtime.so");
}

I tried putting these lines into crates/wasi-common/build.rs, and then libwasmtime.so was built correctly, including a SONAME entry.

Could you please fix this issue?

Thanks
Martin

[bjorn3]

That snippet is wrong if a user of wasmtime wants to rename the library to for example allow multiple versions to be installed at the same time. (common when packaging shared libraries by distros) You could use patchelf --set-soname yourself after building wasmtime as alternative.

[alexcrichton]

Thanks for the report! We actually do something similar for macOS already. @MartinKolbAtWork would you be up for making a PR to update that script? I unfortunately don't really know much about SONAME...

[MartinKolbAtWork]

Hi @alexcrichton ,
as suggested, I added PR #2998
Thanks,
Martin

[MartinKolbAtWork]

Hi @alexcrichton ,

I have a question/proposal on this topic, and I’d like to know your opinion/view.

Like you, I don’t care about that SONAME thing at all. As stated in the title of the issue, the missing SONAME “just” hinders the usage of Wasmtime in a C/C++ based CMake environment.

Wasmtime has both a C API (wasm-c-api) as well as the new C++ API that you mentioned. The vast majority of people using these APIs do have a CMake environment.
So, instead of fiddling around in low-level SONAME entries during packaging, wouldn’t it be better to offer these users of the C and C++ API a native CMake project?
That would make consuming Wasmtime in CMake a matter of a few lines:

FetchContent_Declare(
  wasmtime
  GIT_REPOSITORY    https://github.com/bytecodealliance/wasmtime.git
  GIT_TAG           v0.28.0
)

I can tell you, today that’s a lot more… 😉

I’m sure in wasmtime there are some C++ enthusiasts around that could add the relevant CMakeLists.txt files to the Git repo.
Do you think this would be a valid option? I’m confident that would be a giant leap forward for all those who use Wasmtime via the C/C++ API.

If you think, my suggestion is a valid approach, I'd close this issue and open a new one with the new suggestion.

Thanks
Martin

[alexcrichton]

Yeah that seems reasonable to me to add! I've never worked with CMake in this regard before (maybe others have?) but adding that for consuming the C API seems pretty reasonable to me.

[MartinKolbAtWork]

Hi @alexcrichton,
it seems like @redradist is the CMake expert. Maybe he can throw in his expertise.

I'll close this issue now and hopefully I'll see Wasmtime's CMake friendliness increased over time 👍

Thanks and best regards,
Martin