| ▲ | amelius 13 hours ago |
| But this ruins the entire idea of packaging software in a self-contained way, at least for a large class of programs. It makes me wonder, does the OS still take its job of hardware abstraction seriously these days? |
|
| ▲ | holowoodman 13 hours ago | parent | next [-] |
| The OS does. Nvidia doesn't. |
| |
| ▲ | direwolf20 13 hours ago | parent [-] | | Does Nvidia not support OpenGL? | | |
| ▲ | holowoodman 12 hours ago | parent [-] | | Not really. Nvidia-OpenGL is incompatible to all existing OS OpenGL interfaces, so you need to ship a separate libGL.so if you want to run on Nvidia. In some cases you even need separate binaries, because if you dynamically link against Nvidia's libGL.so, it won't run with any other libGL.so. Sometimes also vice versa. | | |
| ▲ | 11 hours ago | parent | next [-] | | [deleted] | |
| ▲ | direwolf20 12 hours ago | parent | prev [-] | | Does AMD use a statically linked OpenGL? | | |
| ▲ | holowoodman 11 hours ago | parent [-] | | AMD uses the dynamically linked system libGL.so, usually Mesa. | | |
| ▲ | direwolf20 9 hours ago | parent [-] | | So you still need dynamic linking to load the right driver for your graphics card. | | |
| ▲ | holowoodman 9 hours ago | parent [-] | | Most stuff like that uses some kind of "icd" mechanism that does 'dlopen' on the vendor-specific parts of the library. Afaik neither OpenGL nor Vulkan nor OpenCL are usable without at least dlopen, if not full dynamic linking. |
|
|
|
|
|
|
|
| ▲ | direwolf20 13 hours ago | parent | prev | next [-] |
| It does, and one way it does that is by dynamically loading the right driver code for your hardware. |
|
| ▲ | maccard 12 hours ago | parent | prev [-] |
| That’s a licensing problem not a packaging problem. A DLL is a DLL - only thing that changes is whether you’re allowed redistribute it |
