Stream: git-wasmtime

Topic: wasmtime / issue #2951 build: add musl target


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

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.

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

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

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

bjorn3 commented on issue #2951:

Not sure. I think ideally the wasmtime binary would still statically link musl, but libwasmtime.so wouldn't.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2021 at 15:20):

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 in wasmtime-go aren't passing. I'm not sure why, though.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2021 at 19:59):

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 get opa_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
          }
        }
      ]
    }
  ]
}
/ #

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2021 at 20:06):

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

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

alexcrichton commented on issue #2951:

When I ran the tests locally via go test -v in the wasmtime-go repo itself it looked like trap backtraces didn't work?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 22 2021 at 17:34):

srenatus commented on issue #2951:

Sorry for dropping the ball here. Kind of forgotten about it... :|

view this post on Zulip Wasmtime GitHub notifications bot (Oct 05 2021 at 00:36):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 05 2021 at 07:12):

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: Oct 23 2024 at 20:03 UTC