You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
code-server downloads aarch64 version of C/C++ extension (cpptools) on amd64 machine #2120
Make sure any trace of cpptools extension in ~/.local/share/code-server/{CachedExtensionVSIXs,extensions} is removed.
Start code-server and open a window. Install C/C++ from the extension tab and reload when requested.
2 errors appeared:
The language server crashed 5 times in the last 3 minutes. It will not be restarted.
The C/C++ extension failed to install successfully. You will need to repair or reinstall the extension for C/C++ language features to function properly.
Clicking Attempt to Repair will reload the window, and the extension seems to download binaries for x86_64, but after that the first error still appears.
Both after step 3. and step 4, the binary from both the extracted directory and the VSIX itself shows that the binary is AArch64 instead of AMD64 (I don't know where the extension downloads binaries to):
~/.local/share/code-server/extensions/ms-vscode.cpptools-1.0.0$ file bin/cpptools
bin/cpptools: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=a6622307e0c01de448bbd8e6567e33b18d0c26c0, not stripped
The remoteagent.log is obtained at step 2, before reloading (the log level is set to trace). I manually download the extension using URL in the log (starts with https://storage.googleapis.com/vscode-extension-assets), and it contains arm64 binaries. Interestingly, I don't see any architecture parameter in the query.
Workaround: manually download the extension from extension's GitHub release page seems to work correctly. Notice that they're
the "offline" .vsix (that doesn't download OS-based dependencies on extension activation)
I suspect that the store is supposed to distribute "online" .vsix that works on all architecture?
This is a big problem for us as well - we use code-server in Jupyterhub for our undergrad classes. We're using the work around (directly load the extension) but it requires each student to run a script.
[Error - 6:30:36 PM] Connection to server got closed. Server will not be restarted.
/home/jovyan/.local/share/code-server/extensions/ms-vscode.cpptools-1.1.2/bin/cpptools: 7: Syntax error: word unexpected (expecting ")")
and looking at the file
jovyan@jupyter-grunwald:~/.local/share/code-server/extensions$ file ms-vscode.cpptools-1.1.2/bin/cpptools
ms-vscode.cpptools-1.1.2/bin/cpptools: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=1f1d022564fe3736517f4b233ca3286638074a16, not stripped
I'm not familiar enough with the code-server code base to start digging into why this might be happening to avoid the problem in the future.
According to the log file from @peat-psuwit this appears to be trying to download an x64 binary. Is the package perhaps just improperly labeled in storage.googleapis.com?
I suspect that the store is supposed to distribute "online" .vsix that works on all architecture?
Yup, it looks like our marketplace is just uploading the first .vsix it finds in their GitHub releases which is the linux-aarch64 one.
They don't seem to distribute the "online" version there, so the ideal situation would be to have them add it to the GitHub releases so we can make use of it.
Otherwise we'll need to build it ourselves. Either that or modify our marketplace to support multiple versions of an extension then patch the extension gallery code in VS Code to download the right one based on the operating system.
Like separate the repository for different arch?
Or just match the filename while download extensions if there were multiple vsix in a single release.
If we have a x86_64 linux server, it will try to download file name contains x86_64 -> x64-> amd64 -> linux(sort by len(filename)) -> unix -> other
Else if I have a arm64 linux server, it well try to download file name contains aarch64 -> arm64 -> linux(sort by len(filename)) -> unix -> `other
Instead of just download the first vsix from github releases.
Ok. The thing is, the cpptools extension's EULA actually prohibits the use with non-MS version of VSCode. Also, since code-server now uses Open-VSX registry, I'm not sure if this problem is still relevant or not. Maybe Open-VSX have a similar problem?
P.S. if someone want a C/C++ extension that is legal to use on code-server, I recommend clangd's VSCode extension. With properly configured compile_commands.json, it will work better than Microsoft's one.
Excellent point, I think at least as far as code-server is concerned this issue has reached the end of its life. It seems unlikely anything can be done about this as long as the restrictive license is in play but the clangd extension seems like the perfect alternative! Thanks for linking to that.
Activity
welljsjs commentedon Sep 27, 2020
Same here. Currently causing us a bit of a headache.
dirkcgrunwald commentedon Sep 30, 2020
This is a big problem for us as well - we use code-server in Jupyterhub for our undergrad classes. We're using the work around (directly load the extension) but it requires each student to run a script.
goshander commentedon Oct 20, 2020
same issue
ubuntu server 20.04.1
code-server 3.6.0
CPU 1005 after extension installation start
dirkcgrunwald commentedon Nov 22, 2020
This is still an issue in release 3.7.2
and looking at the file
I'm not familiar enough with the code-server code base to start digging into why this might be happening to avoid the problem in the future.
According to the log file from @peat-psuwit this appears to be trying to download an x64 binary. Is the package perhaps just improperly labeled in storage.googleapis.com?
code-asher commentedon Nov 23, 2020
Yup, it looks like our marketplace is just uploading the first .vsix it finds in their GitHub releases which is the linux-aarch64 one.
They don't seem to distribute the "online" version there, so the ideal situation would be to have them add it to the GitHub releases so we can make use of it.
Otherwise we'll need to build it ourselves. Either that or modify our marketplace to support multiple versions of an extension then patch the extension gallery code in VS Code to download the right one based on the operating system.
HuJK commentedon Aug 10, 2021
Any plan to fix this issue?
Like separate the repository for different arch?
Or just match the filename while download extensions if there were multiple vsix in a single release.
If we have a x86_64 linux server, it will try to download file name contains
x86_64->x64->amd64->linux(sort by len(filename))->unix->otherElse if I have a arm64 linux server, it well try to download file name contains
aarch64->arm64->linux(sort by len(filename))->unix-> `otherInstead of just download the first vsix from github releases.
code-asher commentedon Aug 10, 2021
stale commentedon Feb 6, 2022
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.
peat-psuwit commentedon Feb 6, 2022
Ok. The thing is, the cpptools extension's EULA actually prohibits the use with non-MS version of VSCode. Also, since code-server now uses Open-VSX registry, I'm not sure if this problem is still relevant or not. Maybe Open-VSX have a similar problem?
P.S. if someone want a C/C++ extension that is legal to use on code-server, I recommend clangd's VSCode extension. With properly configured
compile_commands.json, it will work better than Microsoft's one.code-asher commentedon Feb 8, 2022
Excellent point, I think at least as far as code-server is concerned this issue has reached the end of its life. It seems unlikely anything can be done about this as long as the restrictive license is in play but the clangd extension seems like the perfect alternative! Thanks for linking to that.