Stream: git-wasmtime

Topic: wasmtime / issue #2996 Linux: Missing SONAME in "libwasmt...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2021 at 12:14):

MartinKolbAtWork opened issue #2996:

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: https://github.com/rust-lang/cargo/issues/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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2021 at 12:22):

bjorn3 commented on issue #2996:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2021 at 14:40):

alexcrichton commented on issue #2996:

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...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2021 at 16:27):

MartinKolbAtWork commented on issue #2996:

Hi @alexcrichton ,
as suggested, I added PR https://github.com/bytecodealliance/wasmtime/pull/2998
Thanks,
Martin

view this post on Zulip Wasmtime GitHub notifications bot (Jun 27 2021 at 11:09):

MartinKolbAtWork commented on issue #2996:

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

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2021 at 14:12):

alexcrichton commented on issue #2996:

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 29 2021 at 06:24):

MartinKolbAtWork commented on issue #2996:

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 :+1:

Thanks and best regards,
Martin

view this post on Zulip Wasmtime GitHub notifications bot (Jun 29 2021 at 06:24):

MartinKolbAtWork closed issue #2996:

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: https://github.com/rust-lang/cargo/issues/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

Last updated: Dec 23 2024 at 12:05 UTC