Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
MartinKolbAtWork opened this issue Jun 18, 2021 · 6 comments
Closed

Comments

@MartinKolbAtWork
Copy link

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
Copy link
Contributor

bjorn3 commented Jun 18, 2021

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
Copy link
Member

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
Copy link
Author

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

@MartinKolbAtWork
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants