Alpine operating system support

[jaudiger]

Type: General
I'm not sure if this issue is already tracked somewhere else. I checked before to open this one, and I only found pull requests talking about disabling the support of the extension under Alpine and ARM environment:

• Implement not supported message for arm platform and alpine containers #4027
• re-enable the supported arch check #4066

Describe the bug

• OS and Version: Alpine 3.11
• VS Code Version: 1.41
• C/C++ Extension Version: 2.26
• C/C++ Extension does not support Alpine environment due to the use of musl library.

I don't know what are the dependencies of the C/C++ Extension since this is not an open source extension. But what is the cost to add the support of musl library in addition of the usual libc library ?

I'm currently looking to mount a development Docker environment based on an Alpine operating system.

[lodo1995]

+1 on this.
I think this feature might get more and more requested given that 1) Remote-Containers is getting more popular to develop on Windows machines without cluttering them 2) Alpine is getting very popular because of its speed, and is starting to support more libraries and tools.

[whitetigle]

Same here, would definitely love to see that coming so that I can use it on gitpod using Alpine. Thanks!

[Trass3r]

So what exactly isn't working and how does it depend on musl?

[sean-mcmanus]

@Trass3r Are you asking us? I think the cpptools/cpptools-srv doesn't run. @andreeis Might know more.

[Trass3r]

Yes, so we get that message alpine is not supported but it's not clear which features are affected.
vscode-cpptools consists of different components. I personally only use the debugger as there are other solutions for LSP.

[sean-mcmanus]

@WardenGnaw Do you know anything about Alpine support for the debugger?

[WardenGnaw]

If there is a Mono Runtime (using musl) that works on Alpine, we can ship the debugger to work on Alpine.

From when I last checked, there was not an officially supported Mono Runtime for Alpine.

[jaudiger]

There is a mono package (https://pkgs.alpinelinux.org/package/edge/testing/x86_64/mono), but it's not ready for production right now. The package is only available on edge branch, not on the 3.12 release. And it's tagged as testing.

[Trass3r]

Indeed. It can be installed via

sed -i -e 's/v[[:digit:]]\..*\//edge\//g' /etc/apk/repositories
apk update && apk upgrade --no-cache --available
apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/testing mono

Then one can test the current state by removing

else if (process.platform === 'linux' && fs.existsSync('/etc/alpine-release')) {
    errMsg = localize(1, null);
}

from ~/.vscode-server/extensions/ms-vscode.cpptools-*/dist/main.js, reloading and running

rm ~/.vscode-server/extensions/ms-vscode.cpptools-*/debugAdapters/mono.linux-x86_64
~/.vscode-server/extensions/ms-vscode.cpptools-1.1.2/debugAdapters/OpenDebugAD7

But...

Got a SIGSEGV while executing native code.

[Trass3r]

Ok it's way easier: https://github.com/sgerrand/alpine-pkg-glibc#installing

[Trass3r]

Related: microsoft/MIEngine#1075 (comment)

[xspeed1989]

Ok it's way easier: https://github.com/sgerrand/alpine-pkg-glibc#installing

@Trass3r It seems doesn't work on alpine 3.14.0?

[xspeed1989]

@Trass3r Are you asking us? I think the cpptools/cpptools-srv doesn't run. @andreeis Might know more.

@sean-mcmanus will cpptools run on alpine?is there a plan?

[Trass3r]

Ok it's way easier: https://github.com/sgerrand/alpine-pkg-glibc#installing

It seems doesn't work on alpine 3.14.0?

I've only tested the debugger. Looks like the workaround doesn't work for IntelliSense yet.

FROM mcr.microsoft.com/vscode/devcontainers/base:dev-alpine-3.14

RUN rm /etc/alpine-release \
&&  wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub \
&&  wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.33-r0/glibc-2.33-r0.apk \
&&  apk add glibc-2.33-r0.apk
ENV LD_LIBRARY_PATH=/usr/glibc-compat/lib:/usr/lib:/lib

$ ~/.vscode-server/extensions/ms-vscode.cpptools-*/debugAdapters/OpenDebugAD7 --help
OpenDebugAD7: Visual Studio Code debug adapter bridge [...]
$ ~/.vscode-server/extensions/ms-vscode.cpptools-*/bin/cpptools --help
 Relink `/usr/lib/libgcc_s.so.1' with `/usr/glibc-compat/lib/libc.so.6' for IFUNC symbol `memset'
Segmentation fault

[sean-mcmanus]

It's in the "On Deck" milestone so it's something we want to address, but we don't know when exactly yet.

[WardenGnaw]

There is a debugger shipped for alpine-x64 just not currently added.

I was not able to fully validate the debugger works in an alpine container with the vscode-containers extension so I have not added it to the list of it being officially supported.

[Trass3r]

@WardenGnaw ah ok so that url is actually the debugger package.

$ cd ~/.vscode-server-insiders/extensions/ms-vscode.cpptools-1.6.0-*/
$ unzip /workspaces/alpinedevcontainer/linux-musl-x64.zip -d .
$ chmod +x debugAdapters/bin/OpenDebugAD7
$ debugAdapters/bin/OpenDebugAD7 --help
OpenDebugAD7: Visual Studio Code debug adapter bridge for using Visual Studio
debug engines in VS Code

Stepping through a program also works, nice!

(Of course you'll get the message Launching server using command /home/vscode/.vscode-server-insiders/extensions/ms-vscode.cpptools-1.6.0-insiders3/bin/cpptools failed without "C_Cpp.intelliSenseEngine": "Disabled")

[WardenGnaw]

@Trass3r Let me know if you notice any issues.

Are you about to get this working via a docker container?

[Trass3r]

Yeah even seems to work without the rm /etc/alpine-release hack, though the code is still there in main.js: util.checkDirectoryExists('/etc/alpine-release').

And you get

Warning: Expected file /home/vscode/.vscode-server-insiders/extensions/ms-vscode.cpptools-1.6.0-insiders3/debugAdapters/OpenDebugAD7 is missing.
Finished installing dependencies

Tested on

FROM mcr.microsoft.com/vscode/devcontainers/base:dev-alpine-3.14
RUN apk add --no-cache gdb
#RUN rm /etc/alpine-release
#RUN apk add --no-cache coreutils wget file \
#	bash icu-libs krb5-libs libgcc libintl libssl1.1 libstdc++ zlib \
#&&	wget https://dot.net/v1/dotnet-install.sh \
#&&	chmod +x dotnet-install.sh \
#&&	./dotnet-install.sh -c 5.0

[WardenGnaw]

Yeah. There's one issue that its checking to see if a directory exists but its actually a file and also needing to just launch the debugger without the language service.

This includes disabling the "Build and Debug Active File".

[WardenGnaw]

@Trass3r Were you able to get a debug session with that given zip?

I used your dockerfile (+ added g++) but I'm running into OpenDebug not getting permissions to setup its fifo queues for terminal redirection.

/tmp/Microsoft-MIEngine-Cmd-dagdg3cq.215: line 2: can't create /tmp/Microsoft-MIEngine-Pid-1vp1f5pp.fe3: Permission denied
[1]+  Done(1)                    "/usr/bin/gdb" --interpreter=mi --tty=${DbgTerm} 0<"/tmp/Microsoft-MIEngine-In-0nzchqtx.e0p" 1>"/tmp/Microsoft-MIEngine-Out-lqsm1oya.2pw"
rm: remove write-protected fifo '/tmp/Microsoft-MIEngine-In-0nzchqtx.e0p'? 

Were you able to get around this issue?

[Trass3r]

Yeah it worked for me, never had this fifo error. Did you use a different user?
I haven't included the devcontainer.json part cause it's the standard generated one anyway.

[WardenGnaw]

Ah, I was able to by pass that initial issue with uncommenting runArgs in devcontainer.json

devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.191.1/containers/alpine
{
	"name": "Alpine",
	"build": {
		"dockerfile": "Dockerfile",
		// Update 'VARIANT' to pick an Alpine version: 3.11, 3.12, 3.13, 3.14
		"args": { "VARIANT": "3.14" }
	},
	
	// Set *default* container specific settings.json values on container create. 
	"settings": {},

	// Add the IDs of extensions you want installed when the container is created.
	// Note that some extensions may not work in Alpine Linux. See https://aka.ms/vscode-remote/linux.
	"extensions": [],

	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],

	// Use 'postCreateCommand' to run commands after the container is created.
	// "postCreateCommand": "uname -a",

	// Uncomment when using a ptrace-based debugger like C++, Go, and Rust
	"runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ],

	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
	"remoteUser": "vscode"
}

Current error I'm looking at is an GDB error in a simple Hello World printf project generated with g++ -g main.cpp -o main

--> E (output): {"type":"event","event":"output","body":{"category":"stderr","output":"ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited with code 2.\n"},"seq":216}
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited with code 2.

My Steps:

1. Launch container using Remote-Containers: Open folder in Container
2. In the Terminal Pane
   1. cd ~/.vscode-server/extensions/ms-vscode.cpptools-1.6.0/
   2. wget https://download.visualstudio.microsoft.com/download/pr/db1a8e6a-c2e7-45a6-9ff9-95fbca2140eb/f536f6270266082d58232b0a6cd9c6c5/linux-musl-x64.zip
   3. rm -rf debugAdapters/
   4. unzip linux-musl-x64.zip
   5. chmod 700 ./debugAdapters/bin/OpenDebugAD7

[Trass3r]

I haven't uncommented runArgs and it still works. The rest of the devcontainer.json is the same. Tested on WSL2.
Replicated your steps and added ./debugAdapters/bin/OpenDebugAD7 --help which works.

[WardenGnaw]

OpenDebugAD7 will run, its during the debug session with GDB that it fails to debug the program.

[Trass3r]

Debugging works for me: https://gist.github.com/Trass3r/55cccb10eb7b9dc72653a67336dd15e8

sudo apk add --no-cache wget unzip
cd ~/.vscode-server/extensions/ms-vscode.cpptools-*
wget https://download.visualstudio.microsoft.com/download/pr/19b0fca0-b008-4b39-9163-6b7a59e50961/f74cb83d6e43dfc2c30a9a0ec46d46b4/linux-musl-x64.zip
unzip -o linux-musl-x64.zip
chmod 700 ./debugAdapters/bin/OpenDebugAD7
./debugAdapters/bin/OpenDebugAD7 --help
rm linux-musl-x64.zip

[WardenGnaw]

Let me give that a shot. One thing I notice is you are using clang to compile and gdb to debug which causes some of variables fail to be visualized.

My scenario was g++ and gdb.

[Trass3r]

Ah, I was able to by pass that initial issue with uncommenting runArgs in devcontainer.json
"runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ],

Ah ok /proc/sys/kernel/yama/ptrace_scope plays a role. It's 1 for me.

[WardenGnaw]

Awesome. I was able to get it to work in your container scenario. I'll be working on getting debugging downloaded / enabled on Alpine.

[dmg0345]

Are there any news about this feature? Would love to use Alpine Linux but this issue is a deal breaker as is. I also work in C/C++ with ARM crosscompilers.

I would like to share a workaround in any case, I have been using an Ubuntu Jammy docker image as an alternative, which works fine and also happens to have almost the latest versions of relevant packages: ARM GCC compiler, Newlib, CppCheck, gdb debugger, clang-format, doxygen, cmake...

[bobbrow]

Next week we hope to have our first preview of Alpine support available.

[sean-mcmanus]

Fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.8.0-insiders3 or 1.8.0 (via using VS Code's "Pre-Release Version" UI or https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools&ssr=false#version-history ).