Open crawfordlong opened 1 year ago
Hi @crawfordlong ! Thanks for raising this. I'm not super familiar with Alpine, TBH. At first I though that perhaps problem might be around either missing or different versions of shared libs. Although, marksman is a mostly-statically linked binary it still links dynamically against some base libs:
$ ldd marksman-linux
linux-vdso.so.1 (0x00007ffe227d5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8c7c600000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f8c7c200000)
libz.so.1 => /lib64/libz.so.1 (0x00007f8c7be00000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8c7ba00000)
librt.so.1 => /lib64/librt.so.1 (0x00007f8c7b600000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8c7b200000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8c7ae00000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8c7aa00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8c7d600000)
So I thought maybe something is missing in Alpine? (Have you tried building from source in an Alpine container?)
However, given that the server actually start (albeit with quite a delay), I'm curious what exactly does not work?
Oh, and thanks for reminding me about libicu problem. It's a bit unfortunate that dotnet wants while Marksman doesn't actually make use of it. So, it's been on my todo list to reconfigure the build to avoid requiring libicu.
I’m not terribly familiar with Alpine either, lol. It’s great as a lightweight container though.
I’m going to do some investigation when I have a minute and will report back.
On May 30, 2023 at 5:22 AM, <Artem Pianykh @.***)> wrote:
Hi @crawfordlong (https://github.com/crawfordlong) ! Thanks for raising this. I'm not super familiar with Alpine, but I'd imagine that the problem might be around either missing or different versions of shared libs. Although, marksman is a mostly-statically linked binary it still links dynamically against some base libs:
$ ldd marksman-linux linux-vdso.so.1 (0x00007ffe227d5000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8c7c600000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8c7c200000) libz.so.1 => /lib64/libz.so.1 (0x00007f8c7be00000) libm.so.6 => /lib64/libm.so.6 (0x00007f8c7ba00000) librt.so.1 => /lib64/librt.so.1 (0x00007f8c7b600000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f8c7b200000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f8c7ae00000) libc.so.6 => /lib64/libc.so.6 (0x00007f8c7aa00000) /lib64/ld-linux-x86-64.so.2 (0x00007f8c7d600000)
Perhaps something is missing in Alpine? Have you tried to build from source in an Alpine container?
— Reply to this email directly, view it on GitHub (https://github.com/artempyanykh/marksman/issues/209#issuecomment-1568092191), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ATWGBHIZJPTNFBFSRSW33S3XIW33PANCNFSM6AAAAAAYKPCBLE). You are receiving this because you were mentioned.Message ID: @.***>
Alpine is based on musl, whereas other linux images/distros are based on glibc.
Based on @artempyanykh's previous comment, it seems that marksman has dependencies on libgcc and other system libraries that are not available on Alpine.
Here is an example output:
$ docker run --rm -it alpine:latest
/ # apk add curl
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/aarch64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/aarch64/APKINDEX.tar.gz
curl(1/7) Installing ca-certificates (20230506-r0)
(2/7) Installing brotli-libs (1.0.9-r14)
(3/7) Installing libunistring (1.1-r1)
(4/7) Installing libidn2 (2.3.4-r1)
(5/7) Installing nghttp2-libs (1.55.1-r0)
(6/7) Installing libcurl (8.2.1-r0)
(7/7) Installing curl (8.2.1-r0)
Executing busybox-1.36.1-r0.trigger
Executing ca-certificates-20230506-r0.trigger
OK: 12 MiB in 22 packages
/ # curl -LO https://github.com/artempyanykh/marksman/releases/download/2023-07-25/marksman-linux-arm64
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 17.7M 100 17.7M 0 0 595k 0 0:00:30 0:00:30 --:--:-- 566k
/ # chmod u+x ./marksman-linux-arm64
/ # ldd marksman-linux-arm64
/lib/ld-linux-aarch64.so.1 (0xffff99f0e000)
libpthread.so.0 => /lib/ld-linux-aarch64.so.1 (0xffff99f0e000)
libdl.so.2 => /lib/ld-linux-aarch64.so.1 (0xffff99f0e000)
libz.so.1 => /lib/libz.so.1 (0xffff994f3000)
libm.so.6 => /lib/ld-linux-aarch64.so.1 (0xffff99f0e000)
librt.so.1 => /lib/ld-linux-aarch64.so.1 (0xffff99f0e000)
Error loading shared library libgcc_s.so.1: No such file or directory (needed by marksman-linux-arm64)
Error loading shared library libstdc++.so.6: No such file or directory (needed by marksman-linux-arm64)
libc.so.6 => /lib/ld-linux-aarch64.so.1 (0xffff99f0e000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by marksman-linux-arm64)
I was able to resolve these missing shared libraries by installing:
/ # apk add build-base gcompat
But now, I get a different error:
/ # ./marksman-linux-arm64
Segmentation fault
On a debian image, I still could not run the pre-built binary:
root@6e9c73cb2746:/# curl -LO https://github.com/artempyanykh/marksman/releases/download/2023-07-25/marksman-linux-arm64
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 17.7M 100 17.7M 0 0 583k 0 0:00:31 0:00:31 --:--:-- 602k
root@6e9c73cb2746:/# chmod u+x ./marksman-linux-arm64
root@6e9c73cb2746:/# ./marksman-linux-arm64
Failed to load System.Private.CoreLib.dll (error code 0x80070002)
Path: /System.Private.CoreLib.dll
Error message: Could not load file or assembly '/System.Private.CoreLib.dll'. The system cannot find the file specified.
(0x80070002)
Failed to create CoreCLR, HRESULT: 0x80070002
root@6e9c73cb2746:/# ldd ./marksman-linux-arm64
linux-vdso.so.1 (0x0000ffffa7385000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffffa6920000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffffa68f0000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffffa68b0000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffa6810000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffffa67e0000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffffa67a0000)
libstdc++.so.6 => /lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffa6580000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffa63d0000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffa7348000)
I am a musl
user, too, and I use Alpine as well. I was more lucky and have not encountered any segfaults so far, but gcompat
is not that reliable in my experience: compatibility with binaries linked against different C libraries implementations is just plain difficult.
I think for starters it should be documented that the binaries are build against glibc. Some projects even add a -glibc
suffix to the binaries filename.
Environment: Fedora Silverblue 38 (host) Alpine distrobox container
Observed Behavior:
First, this may be a case of user error. This is my first go with an lsp solution and helix.
Second, I downloaded the latest (as of yesterday) marksman binary, placed it in
~/.local/bin
, and confirmed that it is in the path both by confirming the path and executinghx --health markdown
. This command shows the presence of marksman in both the base system and within the distrobox container.If I execute hx test.md in the base system (where I don't do any work), everything works smoothly. If, however, I execute the same command or open an existing markdown file from within the container (where I am doing primary work), marksman does not appear to start, though there is a long (3-5 second) lag exiting helix in the container that does not occur on the base system.
Edit: I ran the same
hx test.md
in a Fedora 38 distrobox container, and I received a hard crash indicating that libicu was not installed. After installing libicu, helix started fine and marksman worked perfectly. So this does hint at a possible Alpine issue. If I runmarksman server -v 5
in the alpine container, I get the following output, but it's important to note that the first output appears almost 20 seconds after I execute the command (appears instantly in the Fedora base and container):Questions:
If neither of these applies and it looks like we have a bug of some sort, I will start gathering logs and whatnot. Thank you!