Add musl libc CI using Alpine Linux container on Ubuntu GHA#4650
Add musl libc CI using Alpine Linux container on Ubuntu GHA#4650JohanEngelen merged 6 commits intomasterfrom
Conversation
|
Is there a good way to disable all |
|
Yeah, we have this which should take care of most dmd-testsuite failures: ldc/tests/dmd/tools/d_do_test.d Lines 1702 to 1709 in 40ad5f7 |
666b612 to
0f089fd
Compare
|
The tester on Alpine Linux with musl is green now :)) |
cmake/Modules/FindLLVM.cmake
Outdated
| set(sharedstatic "--link-shared") | ||
| else() | ||
| set(sharedstatic "--link-static") | ||
| endif() |
There was a problem hiding this comment.
Is this stuff really required? Is the alpine llvm package misconfigured?
There was a problem hiding this comment.
Ah, optionally definable manually now, just seen the TODO in the yaml.
There was a problem hiding this comment.
But judging from the ldd output, LLVM is linked statically just fine already, but the other deps aren't (lib{z,zstd,unwind} etc.).
There was a problem hiding this comment.
[I'm pretty sure this broke the FreeBSD job, where explicitly using --link-shared apparently causes libzstd to be dragged in, which isn't installed (so no dependency of the installed official llvm package on that library either) - probably misconfigured by FreeBSD.]
There was a problem hiding this comment.
I had some trouble in shared/static linking of LLVM. The installation defaults to shared linking on Alpine (llvm-config default output), that's why I added this code here. It's perhaps not needed right now (no static linked build).
Fully static linking is not possible yet, because of the libunwind dependency. libunwind is incompatible with g++ static linking, because of conflicting symbols between libgcc_eh and libunwind. I think the only option is to make the libunwind dependency of druntime optional, and disable it for a fully statically linked LDC.
There was a problem hiding this comment.
I need to link into this: libunwind/libunwind#405 (comment)
There was a problem hiding this comment.
Why do you wanna link fully statically anyway? As preparation for an official musl-x86_64 LDC package? That would be quite a bit more work anyway, and would ideally be integrated in the main.yml workflow then, as that performs the upload to GitHub etc. So I'd suggest deferring that to another PR.
There was a problem hiding this comment.
[Btw a friend recently told me that the Alpine gcc is patched in a way that it doesn't emit the x86_64 cmpxch16b instruction. They noticed a ~20% overall performance improvement of glibc vs. musl because of that.]
There was a problem hiding this comment.
I'll defer the static stuff to a different PR. It also requires / will include further simplification / fix of the libunwind backtrace handling. It turns out we can use the same code as what we use on Darwin. Which should then work hopefully for the many different versions of libunwind packages that I'm encountering...
.github/workflows/alpine_musl.yml
Outdated
| ninja obj/ldc2.o all ldc2-unittest all-test-runners | ||
| bin/ldc2 --version | ||
| ldd bin/ldc2 | ||
| shell: alpine.sh {0} |
There was a problem hiding this comment.
You can set this once for the whole job: https://docs.github.com/en/actions/using-jobs/setting-default-values-for-jobs#setting-default-values-for-a-specific-job
There was a problem hiding this comment.
I prefer to write it explicit for each step, so it is more clear that the commands are running in the alpine container inside the ubuntu container.
|
Currently it doesn't find any compiler-rt libs, so |
5dca642 to
e8cdef3
Compare
The pipe through `head` meant that error code was always 0, even when gdb is absent.
…tory structure with major llvm version instead of x.y.z version.
Fixes crash in std.file unittest with optimizations enabled.
|
Green again! |
|
Any objections before merging? With this in place, in follow up I intend to work towards statically linked build and uploading a release to GH. I'll upstream the druntime fix. dlang/dmd#16627 |
Separate PRs to enable musl:
Upstream PRs: