swc-linux-arm64-gnu is not included in the GitHub releases after v1.7.14.

[pan93412]

Describe the bug

f625035 did not fix it.

---

The filename is swc-linux-arm64-gnu.

It was present not after version v1.7.14: v1.7.14 (release). It has now disappeared. I suspect there was a change in the CI, but I cannot find the code that introduced this issue.

Discord discussion: discord.com/channels/889779439272075314/889785438938726441/1290999698328649738.

Input code

N/A

Config

N/A

Playground link (or link to the minimal reproduction)

https://play.swc.rs/?version=1.9.3&code=H4sIAAAAAAAAA0vOzyvOz0nVy8lP11DKSM3JyVfSBAAewMmrFAAAAA%3D%3D&config=H4sIAAAAAAAAA1WPSw7DIAwF9zkF8rrbdtE79BAWdSIifrKJVBTl7iUE0maH3xsz8jooBbNoeKq1PMsQkYX4nEsi2Sf8lARIOxTNJia49XaWvRrRCtVoOxpIyBOluiX3hoMNQajjLXPGmzH%2FC3VwkUnkCu4o%2BsnSVTc0JbjwXmrZDkk50qF%2FwA%2FqsvNjMPLqm4kXGrYvhlQioBQBAAA%3D

SWC Info output

N/A

Expected behavior

N/A

Actual behavior

No response

Version

1.9.3

Additional context

No response

[kdy1]

cc @Brooooooklyn Is linux-arm64-gnu valid napi target?

[Brooooooklyn]

@pan93412 you can use swc-linux-arm64-musl

[pan93412]

@pan93412 you can use swc-linux-arm64-musl

Yes, it works. However, there’s a library that downloads the SWC binary based on the runtime, and the missing of “glibc” prevents the library from downloading the latest SWC binaries. 😢

I may create a PR for that library to ensure it always downloads the musl version if napi-rs would not generate the glibc version anymore.

[pan93412]

I have the similar problem. My version is 1.10.4, platform is darwin and arm64. It throw "Failed to load native binding".

It might not be the same problem. You might need to open another issue to track it well.

[tbarrella]

Hello, I was wondering if I could help with this issue?

It looks like there are already builds for aarch64-unknown-linux-gnu, which I think is the same architecture as linux-arm64-gnu:

swc/.github/workflows/publish-npm-package.yml

Line 143 in f33b0bc

target: aarch64-unknown-linux-gnu

I'm not sure yet how publishing works; maybe a change is needed in one or both of these places to accommodate for the naming difference? and/or creating new directories in packages/ with arm64 -> aarch64?

• https://github.com/swc-project/swc/blob/main/packages/core/scripts/cli_artifacts.sh
• https://github.com/swc-project/swc/blob/main/scripts/cli_upload_gh_release.sh

[guw]

Some findings from the actions/workflow log.

Publish 1.11.15
Publish 1.11.15-nightly

Output of "List binaries":

./packages/core/artifacts/bindings-core-1.11.15-nightly-20250401.1-aarch64-unknown-linux-gnu:
swc.linux-arm64-gnu.node

./packages/core/artifacts/bindings-core-1.11.15-nightly-20250[40](https://github.com/swc-project/swc/actions/runs/14187712145/job/39747289649#step:7:41)1.1-aarch64-unknown-linux-musl:
swc
swc.linux-arm64-musl.node

For aarch64-unknown-linux-gnu the swc binary is missing. This implies that the cp command was not successful either because the output does not exist or it was not run.

Scrolling through the "Build core ..." logs I noticed a possible issue:

115:  sh: 1: [[: not found

This leads me to believe that the cp is not executed because of the interesting command line. The last command executed seems to be rustup target add aarch64-unknown-linux-gnu and then it continues with corepack, skipping everything in between.

An indeed, the syntax is not supported in sh, which is the default shell of the docker-run-action action. See their doc for using bash.

[guw]

@kdy1 I'd appreciate if you can push a release next, validating that this works and unblocking downstream consumers.

[kdy1]

https://github.com/swc-project/swc/actions/runs/14194792959

I did, thanks!

[kdy1]

Reopening as #10303 regressed Wasm plugins on x86_64-unknown-linux-gnu and I'm going to revert it

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.