Add musl libc CI using Alpine Linux container on Ubuntu GHA

[JohanEngelen]

Separate PRs to enable musl:

• Fix libunwind backtraces & Make defaulttraceinfo more generic. #4639
• Fix crashing core.thread.fiber unittest for AArch64. #4648
• Detect musl in cmake and link with libunwind #4645

Upstream PRs:

• Only test druntime exceptions gdb test case (rt_trap_exceptions_drt_g… dlang/dmd#16513
• Fix https://issues.dlang.org/show_bug.cgi?id=24546 for musl libc dlang/dmd#16507
• Rename gdb test case file such that it starts by "gdb" like the other… dlang/dmd#16458

[JohanEngelen]

Is there a good way to disable all gdb-related tests? (the gdb version on Alpine is too new and there are no alpine packages for older gdb versions)

[kinke]

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

	version (LDC)
	{
	if (test_base_name.startsWith("gdb") && environment.get("GDB_FLAGS") == "OFF")
	{
	writefln(" ... %-30s [DISABLED due to GDB_FLAGS=OFF]", input_file);
	return 0;
	}
	}

[JohanEngelen]

The tester on Alpine Linux with musl is green now :))

[kinke]

Is this stuff really required? Is the alpine llvm package misconfigured?

[kinke]

Ah, optionally definable manually now, just seen the TODO in the yaml.

[kinke]

But judging from the ldd output, LLVM is linked statically just fine already, but the other deps aren't (lib{z,zstd,unwind} etc.).

[kinke]

[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.]

[JohanEngelen]

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.

[JohanEngelen]

I need to link into this: libunwind/libunwind#405 (comment)

[kinke]

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.

[kinke]

[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.]

[JohanEngelen]

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...

[kinke]

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

[JohanEngelen]

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.

[kinke]

Currently it doesn't find any compiler-rt libs, so LDC_INSTALL_LLVM_RUNTIME_LIBS_OS might need tweaking.

[JohanEngelen]

Green again!

[JohanEngelen]

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