4 ms·

> I'm a little surprised they chose dynamic over static linking. Yep, it's worth noting that the vast majority of closed source games I've encountered on Linux

> I'm a little surprised they chose dynamic over static linking. Yep, it's worth noting that the vast majority of closed source games I've encountered on Linux are static linked. For what it's worth (as a big proponent of dynamic linking and the maintainer model) I think that's totally fine. I wish there were no closed source applications to begin with, but if there have to be these programs, the process necessarily bypasses the model of maintainer quality control and patching. Games are supposed to be very long lived anyway, once they're past the initial period of getting regular bug fixes.

zxzax 5y ago
Depending on how you build SDL2, your application could be entirely statically linked at build time, but you could still be using libraries dynamically loaded at runtime for other necessary system components: https://github.com/libsdl-org/SDL/blob/c59d4dcd38c382a1e9b69b053756f1139a861574/src/video/x11/SDL_x11dyn.c#L153 https://github.com/libsdl-org/SDL/blob/c59d4dcd38c382a1e9b69... This is a hard requirement if your application uses OpenGL or Vulkan, you can't really statically link those libraries at all, and you have to use dlopen/dlsym to check each individual function in order to support extensions.
- Arnavion 5y ago
  They're not bundling libX11, etc in any case, only SDL. So I don't see why it matters that SDL in turn depends on other system components. Presumably it's looking for said components in a way that works on all the distros they tested. So for the specific libraries that they're dealing with in the blog post (libc and SDL), static linking would probably be easier than what they're doing.
  - zxzax 5y ago
    It doesn't particularly matter, I'm just addressing a common misconception. Dynamic linking doesn't have to happen only at build time and it doesn't have to depend on any particular symbols being present. Even if you static link your libc and SDL, you're still likely going to be doing some dynamic linking at runtime, and in most cases this is probably what you want. You just don't have to handle it yourself because it's implemented within SDL -- it handles all the version detection logic at runtime for you and can decide how to handle things based on the existence of some symbols, so with that it's possible to support multiple version of the same dynamic library, within the same program, and without a recompile.
    - rubicks 5y ago
      Exactly, alternatives to dynamic linking can go either way: static linking if you make decisions earlier or dynamic loading (via libdl) if you make decisions later.

zxzax 5y ago

Depending on how you build SDL2, your application could be entirely statically linked at build time, but you could still be using libraries dynamically loaded at runtime for other necessary system components: https://github.com/libsdl-org/SDL/blob/c59d4dcd38c382a1e9b69b053756f1139a861574/src/video/x11/SDL_x11dyn.c#L153 https://github.com/libsdl-org/SDL/blob/c59d4dcd38c382a1e9b69... This is a hard requirement if your application uses OpenGL or Vulkan, you can't really statically link those libraries at all, and you have to use dlopen/dlsym to check each individual function in order to support extensions.

Arnavion 5y ago
They're not bundling libX11, etc in any case, only SDL. So I don't see why it matters that SDL in turn depends on other system components. Presumably it's looking for said components in a way that works on all the distros they tested. So for the specific libraries that they're dealing with in the blog post (libc and SDL), static linking would probably be easier than what they're doing.
- zxzax 5y ago
  It doesn't particularly matter, I'm just addressing a common misconception. Dynamic linking doesn't have to happen only at build time and it doesn't have to depend on any particular symbols being present. Even if you static link your libc and SDL, you're still likely going to be doing some dynamic linking at runtime, and in most cases this is probably what you want. You just don't have to handle it yourself because it's implemented within SDL -- it handles all the version detection logic at runtime for you and can decide how to handle things based on the existence of some symbols, so with that it's possible to support multiple version of the same dynamic library, within the same program, and without a recompile.
  - rubicks 5y ago
    Exactly, alternatives to dynamic linking can go either way: static linking if you make decisions earlier or dynamic loading (via libdl) if you make decisions later.