SoLo：静态二进制加载动态GPU驱动
Solo – a .so loader for static Linux binaries
在Linux上部署静态二进制文件通常意味着放弃GPU加速，因为静态编译的musl程序无法直接加载基于glibc的Vulkan或OpenGL驱动。SoLo项目打破了这一限制，它作为一个内嵌的.so加载器，让单个静态可执行文件能够安全地调用系统现有的动态图形驱动。无需容器、AppImage或额外的libc，SoLo通过实现glibc ABI桥接和完整的ELF加载逻辑，实现了C++异常跨域传递、TLS模型兼容等复杂功能。开发者只需分发一个文件，即可在AMD、Intel、NVIDIA甚至Apple M1设备上运行高性能图形应用，真正实现了“主机保留硬件代码，你分发其余一切”的极简部署愿景。
主机保留硬件特定的代码，你分发其余一切。
HN 评论区
235- comex
这是一个巨大的向前兼容性风险。假设 glibc 添加了一个新符号，随后某个 GPU 驱动依赖了这个符号。用户想配合更新后的 GPU 驱动运行一个旧的可执行文件（也许旧驱动不支持他们的 GPU）。通常情况下，这完全没问题：用户只需使用新版 glibc，它既能兼容新 GPU 驱动，也能兼容旧可执行文件。但采用你的方案，GPU 驱动被迫使用那个被静态链接进可执行文件中的 glibc 重实现版本。而由于可执行文件是旧的，它绝不可能实现这个新符号。
如果 glibc 为现有符号添加了新版本，随后 GPU 驱动重新编译，也会发生同样的问题。（或者，更广泛地说，如果 GPU 驱动依赖了一个 glibc 一直支持但你重实现的子集中没有的符号，理论上如果你重实现了 100% 的符号，这倒是能解决。）
- eqvinox
如果你能搞定自己的 ELF 加载器，那你也能搞定如何构建一个不需要这种方案的半静态可执行文件。你可以混合使用静态链接和动态链接。围绕这一点的构建工具链简直是一团糟。
- nomel
我对 musl 不太了解。
> GPU：Vulkan 和 OpenGL 驱动由主机以共享对象形式提供，通常针对 glibc 构建，完全静态的 musl 二进制文件通常无法 dlopen() 它们。
为什么？难道有人把共享库这个古老的概念搞崩了，而这是对此的修复吗？
- pg83
这与现有技术有何不同（为何更好！） - https://github.com/pg83/solo#how-this-differs-from-prior-wor...
- socceroos
大家是说 "so"，"ess-oh" 还是 "dot-ess-oh"？对于 "ess-oh" 派的人来说，标题里的 "a .so" 读起来很别扭。
- setheron
如果你动态地卖了一个 SO，那你还是静态的吗，哪怕你是“定制”的？
到了那一步，它不就是换个名字的动态加载器吗？
- simonask
这充分证明了 GNU/Linux 用户空间的彻底失败，以至于像这样的东西竟然显得值得花时间去研究（或者，看起来，值得消耗 LLM token）。
其实不对，因为 Windows 和 macOS 在 ABI 兼容性上也一直 struggle（macOS 稍微好点，因为它们压根就不在乎向后兼容性）。
我们是怎么走到这一步的，人们觉得需要费尽周折地在二进制文件中嵌入一个 ELF 加载器（！！），而不是直接链接 glibc？
- catlifeonmars
所以并不是完全静态，因为它必须链接一个 libc :P