Build broken on musl

[min4builder]

I am building from a musl system. When building with -Dtarget=x86_64-linux-gnu, it works normally. When building for x86_64-linux-musl, it's missing the <dbus/dbus-arch-deps.h> include. I was able to trace it to the following lines in the build.zig:

if (target.result.cpu.arch == .x86_64 and target.result.abi.isGnu()) {
    sdl_mod.addSystemIncludePath(deps_values.dependency.path("include/x86_64-linux-gnu"));
}

It turns out these files are identical between linux-gnu and linux-musl (at least on x86_64), so the check for specifically gnu makes the header go missing. Removing it from my local copy fixed my build.

[castholm]

This package only supports glibc, I have not tested it against musl. I don't have the resources to tailor and test the package extensively for musl-based systems, but if there's a simple fix that makes the build work for musl I could probably relax some of the checks.

However, have you tested your workaround against a non-trivial application that uses video, audio, controller input, etc. and verified that the SDL application runs correctly in practice? This package's hard-coded configuration values and headers vendored/generated by SDL_linux_deps/vendor.sh are based on what works for glibc-based systems, so even if including those headers makes the program compile for musl doesn't necessarily mean it will behave correctly at runtime.

[min4builder]

I tested the sample programs from zig-examples and they work. In fact, my (musl) system headers are identical to the headers this package generates.

Musl uses the same OS/compiler ABI as glibc, so generally this isn't a problem. But to be extra sure, I checked the source code for both dbus and glib.

The dbus build system just sets those macros by testing the compiler ABI, so for dbus, it's completely irrelevant which libc is being used.

The glib build system does something similar for most types, but also checks some libc functions as well. However, at least on x86_64, the results are exactly the same as glibc (the generated files are identical). Most of these checks seem to be for non-standard libcs, Windows in particular. And musl implements the GNU extensions glib wants anyway. I expect the same result on aarch64 as well, though I could check if you want.

The "simple fix" in this case would probably be just to remove the isGnu() check, or possibly add an or ...isMusl() check.

[castholm]

If there were no issues that's great, seems like we can go ahead and include musl in those checks then.

However, before I make the changes, if you don't mind I would appreciate if you could you help me out and verify some details:

• Could you tell me which specific distro you use?
• Could you clone the upstream https://github.com/libsdl-org/SDL, check out the release-3.2.14 tag, run cmake -S . -B build '-DCMAKE_C_COMPILER=zig;cc' to configure the build (no need to actually compile) and then share the contents of ./build/include-config-*/build_config/SDL_build_config.h here? I mainly just want to see what the generated config header looks like when building natively for a musl system to see if there are any noteworthy differences compared to glibc systems.

[min4builder]

Of course! I use Alpine Linux (x86_64). Here's a copy of the generated SDL_build_config.h.

[castholm]

Thanks for the help and your patience, and apologies for the delay! I took a look at the config headers as well as the glib/dbus arch-specific headers from the Alpine Linux package index and pushed some fixes to the main branch (0ab7c98). I'll wait for you to confirm that the project builds on your system with these changes before I close the issue.

[undo-k]

Hi @castholm, I'm running Chimera Linux (x86_64-linux-musl) and I'm now able to run the zig-examples using your latest commit. I found myself here 10 minutes ago searching for a fix for the 'dbus/dbus-arch-deps.h' file not found error, and I'm grateful you've addressed this issue in a rapid manner. Thanks.

[min4builder]

Hello again. Sorry for the wait. I was able to run the zig-examples, by just updating their version dependencies to the master branch. My own code is also working now. Thank you very much!