C API: dylib on macOS has ID with rpath

[turbolent]

trafficstars

Describe the bug

Similar to https://github.com/bytecodealliance/wasmtime/issues/984:

On macOS, the built dylib has an ID with a relative path, @rpath:

$ otool -L wasmi/lib/libwasmi.dylib
wasmi/lib/libwasmi.dylib:
	@rpath/libwasmi.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0

Loading the dynamic library then results in

Library not loaded: @rpath/libwasmi.dylib

Reason: no LC_RPATH's found

Expected behavior

Loading the built dynamic library should work.

To Reproduce

1. What Wasmi version was used?

68205d4

2. Bug occurs on Wasmi CLI or Wasmi library?

Wasmi C library

3. Ideally please provide minified Wasm (.wasm) or Wat (.wat) file to reproduce.

N/A

4. Follow steps in https://lib.rs/crates/wasmi_c_api_impl

5. Link against the dylib and run the binary

[turbolent]

I've solved this for now by post-processing the library manually with e.g.

$ install_name_tool -id libwasmi.dylib libwasmi.dylib

wasmtime has a build step to do this automatically, this could be maybe adopted here: https://github.com/bytecodealliance/wasmtime/blob/06377eb08a649619cc8ac9a934cb3f119017f3ef/crates/c-api/CMakeLists.txt#L108-L114

[Robbepop]

@turbolent Thanks a lot for the issue report! Since you already know what needs to be done (e.g. Wasmtime's solution), would you be willing to open a PR? :)

[turbolent]

It looks like wasmi's CMake configuration already has code for this: https://github.com/wasmi-labs/wasmi/blob/7a302a98654523e631ae0d896d4d22911445b6b8/crates/c_api/CMakeLists.txt#L115-L133

I'm not familiar enough with the macOS linker to say what the behaviour should be.