Client(ppc64, riscv64, loong64): missing dependency

[daiyam]

Hi @lex-ibm @darkyzhou @kxxt,

The client is using the new dependency: @vscode/os-proxy-resolver but have a package for each architecture: https://www.npmjs.com/search?q=os-proxy-resolver

ppc64, riscv64, loong64 aren't supported.

I did make a fork and tried to add them: VSCodium/os-proxy-resolver#1
But one of the Rust dependency doesn't support them: https://github.com/DelSkayn/rquickjs (loong64 seems supported but I can't get it to that point).

Since it will take a least a few days to get that figured out, I will disable those client versions for the next release.
If you could take a look, it would be great. Since to implement the support, it would require some testing on the hardware.

[kxxt]

I think we can disable the pac-engine feature which compiles quickjs-ng for the target architecture.

But the wasmtime way does not appear to work for riscv64, either:

❯ cross build --target riscv64gc-unknown-linux-gnu --no-default-features --features "tokio pac-engine-wasmtime " --examples                 
info: syncing channel updates for stable-x86_64-unknown-linux-gnu

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.98.0 (88d9e12ae 2026-08-18)

info: self-update is disabled for this build of rustup
info: any updates to rustup will need to be fetched with your system package manager
   Compiling os-proxy-resolver v0.1.0 (/project)
error: failed to run custom build command for `os-proxy-resolver v0.1.0 (/project)`

Caused by:
  process didn't exit successfully: `/target/debug/build/os-proxy-resolver-d42ea332a83a18c7/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-env-changed=OS_PROXY_RESOLVER_PAC_GUEST_WASM
  cargo:rerun-if-changed=pac-wasm-guest/pac_guest.wasm

  --- stderr

  thread '<unnamed>' (86) panicked at /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cranelift-codegen-0.133.1/src/isa/riscv64/inst/args.rs:1271:18:
  internal error: entered unreachable code
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

  thread 'main' (85) panicked at build.rs:63:18:
  PAC guest compiler thread panicked: Any { .. }

Perhaps the wasm2c approach will work. The default cross-rs container is missing the wasm2c tool so I will try it later.

[kxxt]

Perhaps the wasm2c approach will work. The default cross-rs container is missing the wasm2c tool so I will try it later.

It works. The workflow pre-generates the required files outside the cross-rs container so there is no need to install wasm2c in the container.

But it appears that loong64 is missing the cross-rs docker image for both -musl and -gnu.

https://github.com/kxxt/os-proxy-resolver/actions/runs/33764639532/job/100679276876
VSCodium/os-proxy-resolver#2

[kxxt]

But it appears that loong64 is missing the cross-rs docker image for both -musl and -gnu.

It turns out cross-rs didn't publish the docker image for loong64 when 0.2.5 is published. This is fixed by switching to the :edge image for loong64. But a test still fails for loong64 https://github.com/kxxt/os-proxy-resolver/actions/runs/33767405145/job/100688685757 while it passes on riscv64 and ppc64le.

[darkyzhou]

But it appears that loong64 is missing the cross-rs docker image for both -musl and -gnu.

It turns out cross-rs didn't publish the docker image for loong64 when 0.2.5 is published. This is fixed by switching to the :edge image for loong64. But a test still fails for loong64 https://github.com/kxxt/os-proxy-resolver/actions/runs/33767405145/job/100688685757 while it passes on riscv64 and ppc64le.

I think the test fails because async_resolution_worker_processes_second_distinct_request re-spawns the test binary as a nested child process, and under the cross jobs that nested exec can never actually run: the hosted runner has no binfmt registered, and cross-rs 0.2.5 doesn't register it either. The test already tolerates the two ways, as this plays out on the older images by spawning error ENOENT/ENOEXEC and child exit code 2, but on loong64 the child exits with 127 instead, which isn't covered.

It seems this is due to the guest glibc version: on loong64's :edge image (glibc >= 2.24) the failed nested spawn slips through qemu-user and the child exits 127, while the older images report it as errno 8 or exit code 2. I ran the aarch64 build with the same :edge image and it also fails with 127. This could be fixed by treating exit code 127 like exit code 2 in tests/async_resolution.rs, e.g. matches!(status.code(), Some(2) | Some(127)).

[daiyam]

For loong64, I did use the musl version since ripgrep use the musl one (https://github.com/VSCodium/vscodium/blob/master/build/linux/loong64/ripgrep.sh)
So is it musl or libc? Or you are using a distro which support both?

For the error code, I leave the decision to you ;)

[kxxt]

It seems this is due to the guest glibc version.

For loong64, I did use the musl version since ripgrep use the musl one (https://github.com/VSCodium/vscodium/blob/master/build/linux/loong64/ripgrep.sh) So is it musl or libc? Or you are using a distro which support both?

I can confirm that the tests pass with musl for loong64. But it appears that the built node addon links to musl dynamically.
So I think this is for distributions like alpine instead of normal glibc distros. As for the ripgrep case, since it links to musl libc statically, it could work on both glibc and musl distros. So I think we need the gnu variant of the cross-rs image here.

 loongarch64-linux-gnu-readelf -a /home/kxxt/repos/os-proxy-resolver/npm/native/target/loongarch64-unknown-linux-musl/loongarch64-unknown-linux-musl/release/libos_proxy_resolver_node.so | grep -i NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]

This could be fixed by treating exit code 127 like exit code 2 in tests/async_resolution.rs, e.g. matches!(status.code(), Some(2) | Some(127)).

I updated my PR and the CI is green now https://github.com/kxxt/os-proxy-resolver/actions/runs/33885967125.