Problem transferring executable from Alpine to Mint

[rainerdeyke]

I managed to successfully build a statically linked SDL3 using musl on an Alpine Linux Docker instance with most (but not all) optional dependencies. I then linked this SDL3 into a fully statically linked executable. However, when I try to run the executable on Linux Mint, SDL_Init fails with the ever-so-helpful error message "Failed to initialize SDL: No available video device". Even running with SDL_LOGGING="*=trace" doesn't yield any more helpful information.

The program failing is undesirable but not entirely unexpected. The lack of information in the error message and the log output are what really bother me.

Full output of my program:

App name: Moonshard
App version: 0.0.0
App ID: com.eldwood.moonshard
SDL revision: SDL-release-3.4.2-0-g683181b47
[2026-05-06 16:09 err] Failed to initialize SDL: No available video device

I have attached the relevant-seeming parts of the SDL3 build output.

build_log.txt

[rainerdeyke]

I think I found the problem. SDL3 detects the location of the X11 libraries at configure time and hardcodes them into the library. Under Alpine, the libraries are found in /usr/lib/, but under Mint, they are in /usr/lib/x86_64-linux-gnu/. The obvious fix is to not hardcode the library path, but to search for the correct path at runtime.

[madebr]

Do you mean the runpaths? Those are built-in in the library in your build directory, but are removed when installing.
Can you please share include-config-<CONFIG>/build_config/SDL_build_config.h? It can be found in your build directory. Replace <CONFIG> with your build type. It's probably Release.

[rainerdeyke]

OK, my bad, it seems that the paths aren't hardcoded after all, just the filenames - which are the same filenames on both Alpine and Mint.

SDL_build_config.h attached (with extra .c extension because Github doesn't like .h files).

SDL_build_config.h.c

[rainerdeyke]

Found the problem. It seems that dlopen in statically linked musl is just a stub that doesn't do anything. It does set an error message to that effect, but SDL_Init swallows it.

So it seems my options are:

• Statically link all SDL dependencies.
• Link to musl dynamically, and distribute it with my game.
• Distribute separate musl and glibc builds, both dynamically linked to the system library.
• Use a trick like this or this to get access to a dynamic linker from a statically linked executable.

Anyway, this does not appear to be a SDL issue aside from the unhelpful error message.

Edit: actually, if dlopen is not working, then SDL should probably detect this at configure time and automatically use static linking instead of dlopen. So this is a SDL issue after all.