Open andreamah opened 1 year ago
If you have trouble with the real fix and you want to do a quick fix to get out in Insiders, maybe we can do something where we ship the old version of the binary just for this one arch, and the others continue using the latest.
If you find there are perf costs to using musl, you can instead build on container targets that aligns the minimum GLIBC with VSCode server.
For armhf - we build on Debian buster https://github.com/microsoft/vscode-linux-build-agent/blob/main/buster-armhf/Dockerfile For arm64 - we build on Centos7 Devtoolset8 https://github.com/microsoft/vscode-linux-build-agent/blob/main/centos7-devtoolset8-arm64/Dockerfile
Related: https://github.com/microsoft/vscode/issues/179121#issuecomment-1498077103
It seems like systems that use
arm-unknown-linux-gnueabihf
looks forGLIBC_2.29
despite vscode supporting lower GLIBC versions. This is since that prebuilt is still not statically compiled, so building it againstubuntu-latest
likely increased the GLIBC version that it required from dynamically linked dependences.We should try to make this prebuilt statically compiled by using the musl version, as we did with https://github.com/microsoft/vscode-ripgrep/issues/34