bjorn3 commented on issue #2951:
Does it work with
RUSTFLAGS="-Ctarget-feature=-crt-static"
? With a statically linked libc as is the current default for musl in rustc (will likely change in (near) the future) it is not possible to make a dynamic library.
srenatus commented on issue #2951:
@bjorn3 I'm afraid I'm new to this. Where would I set this? For all the test targets, or should I add another overwrite to the test matrix...?
bjorn3 commented on issue #2951:
Not sure. I think ideally the wasmtime binary would still statically link musl, but libwasmtime.so wouldn't.
alexcrichton commented on issue #2951:
Thanks!
We recently spent some time driving down CI costs so I'm not sure if we can add a test builder just yet, but I do think that this should get the tests passing on CI to see if the target actually works. Using the library built from this PR's CI I added it to
wasmtime-go
but the tests inwasmtime-go
aren't passing. I'm not sure why, though.
srenatus commented on issue #2951:
@alexcrichton what did you encounter? I've played with the CI artifact myself, and in this branch (note the manual changes to vendor/), it seems I'm able to use wasmtime just fine (used
make ci-go-ci-build-linux
to getopa_linux_amd64
):$ docker run -it -v $(pwd):/src alpine:latest / # /src/_release/0.29.3/opa_linux_amd64 version Version: 0.29.3 Build Commit: Build Timestamp: 2021-05-28T19:52:23Z Build Hostname: 195caee59aad Go Version: go1.16.3 WebAssembly: available / # ldd /src/_release/0.29.3/opa_linux_amd64 version /lib/ld-musl-x86_64.so.1 (0x7f0dad478000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7f0dad478000) / # /src/_release/0.29.3/opa_linux_amd64 eval -t wasm 'numbers.range(1, 10)' { "result": [ { "expressions": [ { "value": [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ], "text": "numbers.range(1, 10)", "location": { "row": 1, "col": 1 } } ] } ] } / #
srenatus edited a comment on issue #2951:
@alexcrichton what did you encounter? I've played with the CI artifact myself, and in this branch (note the manual changes to vendor/), it seems I'm able to use wasmtime just fine (used
make ci-go-ci-build-linux
to getopa_linux_amd64
):$ docker run -it -v $(pwd):/src alpine:latest / # /src/_release/0.29.3/opa_linux_amd64 version Version: 0.29.3 Build Commit: Build Timestamp: 2021-05-28T19:52:23Z Build Hostname: 195caee59aad Go Version: go1.16.3 WebAssembly: available / # ldd /src/_release/0.29.3/opa_linux_amd64 version /lib/ld-musl-x86_64.so.1 (0x7f0dad478000) libc.so => /lib/ld-musl-x86_64.so.1 (0x7f0dad478000) / # /src/_release/0.29.3/opa_linux_amd64 eval -t wasm 'numbers.range(1, 10)' { "result": [ { "expressions": [ { "value": [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ], "text": "numbers.range(1, 10)", "location": { "row": 1, "col": 1 } } ] } ] } / #
Update overall, CI doesn't look that happy. This one is interesting, https://github.com/open-policy-agent/opa/runs/2697377478?check_suite_focus=true#step:3:513, I suppose.
alexcrichton commented on issue #2951:
When I ran the tests locally via
go test -v
in thewasmtime-go
repo itself it looked like trap backtraces didn't work?
srenatus commented on issue #2951:
Sorry for dropping the ball here. Kind of forgotten about it... :|
simar7 commented on issue #2951:
Sorry for dropping the ball here. Kind of forgotten about it... :|
hi @srenatus are you still working on this? Just a metric for user report: We ran into this while building a project that uses OPA wasm target.
srenatus commented on issue #2951:
@simar7 I've not been persuing this because it wasn't a priority for us. If you'd like to followup this, the contribution would sure be welcome!
Last updated: Nov 22 2024 at 17:03 UTC