Chimera Linux has described how it got NVIDIA's proprietary graphics drivers working on its musl-based system, tackling a compatibility problem that has limited hardware choices for users of such distributions. Its November 6 engineering report covers the 580 and 620 driver branches. The packaging remains unfinished, and the approach requires a modified C library.
The distinction matters if you're considering Chimera for an NVIDIA machine: this is working compatibility code under development, with limited hardware reports. MrKeyoor has reviewed the engineering account and linked pull request, but has not installed the packages or tested a GPU.
Why a compatibility library wasn't enough
NVIDIA's proprietary userspace libraries are built for glibc, while Chimera uses musl. Both provide C runtime facilities, but the driver expects behavior that stock musl doesn't supply. Chimera's report describes using a recent Git revision of gcompat, which supplies some glibc interfaces, then rewriting the driver's library dependencies with patchelf. The latest tagged gcompat release lacked symbols the driver needed.
Resolving those missing symbols still left a loader error. The driver uses GNU indirect functions, a mechanism that selects a function implementation at runtime. Chimera adapted existing Alpaquita patches to handle the required relocations, packaging its modified library as musl-nvidia, according to the write-up.
Loading OpenGL exposed another mismatch. Parts of the driver expect thread-local storage at fixed offsets, even when their libraries are loaded after a program starts. The developer patched musl's dynamic linker to reserve spare storage for that case, avoiding the need to preload the graphics library into every process.
Clean loader output still led to a hang
The most useful warning in the development account comes after the missing-library errors disappeared: graphical programs hung during hardware testing. A recursive mutex, which allows the same thread to acquire a lock again, was being treated incorrectly because glibc and musl encode its type in different places.
The fix was another shim. It translates the mutex type before forwarding lock operations to musl, while patchelf redirects the driver's calls to those wrappers. For distribution maintainers, the sequence explains why a clean ldd result cannot establish that a proprietary driver runs correctly: the loader can find every symbol while the two runtimes still disagree about the data those functions receive. That conclusion follows from the reported hang and fix, rather than from a separate MrKeyoor test.
What the hardware reports establish
The developer assembled a test machine with a GTX 980 Ti. In a November 4 pull-request comment, q66 reported OpenGL and Vulkan working with the 580 driver. The November 6 post also relays a report that the 620 branch works on an RTX 3070 Ti and another that AArch64 works at least partially. Those latter results are reports received by the developer, not tests independently reproduced for this article.
The project's stated next steps are further packaging refinement and testing. Watch for results tied to specific cards and driver branches before relying on this work for your own machine. The current evidence supports a route through the compatibility problems; it leaves broader hardware reliability to be established.