🐛 Could not start dynamically linked executable: ./biome-linux-x64

[Zaczero]

VS Code version

1.89.1

Extension version

2.2.3

Biome version

1.7.3

Operating system

• Windows
• macOS
• Linux

Description

The bundled biome cli uses a dynamically linked release. This is not a good choice since it introduces several hidden dependencies on the end users and limits the compatibility:

• linux-vdso.so.1
• libgcc_s.so.1
• libpthread.so.0
• libm.so.6
• libdl.so.2
• libc.so.6

The biome-linux-x64-musl release is statically linked, meaning that it has no external dependencies and all necessary code is contained within the binary. This is the best choice if talking compatibility.

Please consider using a self-contained binary for the use within the extension.

Steps to reproduce

N/A

Expected behavior

Extensions uses statically linked biome cli release.

Does this issue occur when using the CLI directly?

Not sure / Not applicable

Logs

No response

[nhedger]

Moving this to the main repo, as it's related to the cli.

[Zaczero]

@nhedger Hey! The main project already provides statically linked builds. I included them in the screenshot for comparison. It's just the extension using a binary with runtime dependencies. Sorry for the lack of clarification.

[azuline]

I have this issue with biome installed from npm, running in the shell.

[ematipico]

I don't have the knowledge around the topic discussed, but PRs are welcome

[Zaczero]

@ematipico As far as I know, there is nothing to do on the biomejs/biome side. This repository already provides statically linked biome-linux-x64-musl releases. It's up to the VSCode extension to use it.

[ematipico]

I see, then I will move back the issue in the VSCode repository

[ematipico]

@nhedger The issue here is that the *-musl binaries aren't correctly picked:

• https://www.npmjs.com/package/@biomejs/cli-linux-arm64-musl
• https://www.npmjs.com/package/@biomejs/cli-linux-x64-musl

There's a specific code that we can to understand if an OS needs the musl binary:

https://github.com/biomejs/biome/blob/bdc6e14d6783b8f95c237781a41d7dc509fc1182/packages/%40biomejs/biome/bin/biome#L5-L18

[Zaczero]

@ematipico It appears that this code snippet will not work in the NixOS case. NixOS is glibc-based but prevents dynamically linked executables (via custom /lib64/ld-linux-x86-64.so.2). Is there any reason for simply not using the musl release on all systems? Statically linked programs can run anywhere without additional dependencies, be it a glibc system or a musl system. If the musl binary was not statically compiled, then indeed it would require a musl-compatible system, but this is not the case here.

[nhedger]

@Zaczero No specific reason other than we never looked into it. I personally don't have a lot of experience with musl, so I never assumed that it was possible. Are we certain that there are no trade-offs ?

[ematipico]

@Zaczero would you have time to send a PR?

[Zaczero]

@nhedger @ematipico I can prepare a PR and the change would be straightforward. The question is whether it's fine to use musl builds globally. Given my understanding, x64 statically compiled binaries will work on all x64 systems, as they have no external dependencies. They are basically self-contained. It doesn't matter what system they are running on because they are independent. In the situation where the glibc build is not statically compiled, it has an external dependency on glibc, which makes it incompatible with Alpine/NixOS/and similar. Additional info on the wiki.