4 ms·

While the detail provided is plentiful, the article reads less like a technical guide and more like a story of how windows devs learned the caveats and tradeoff

While the detail provided is plentiful, the article reads less like a technical guide and more like a story of how windows devs learned the caveats and tradeoffs inherent to dynamic linking/loading. I'm glad it was written and I'm glad to read it, but I'm a little surprised they chose dynamic over static linking. Yes, by default on most major linux distributions, you're at the mercy of the runtime loader. You either live with the complications associated with shared objects, or you change your linker invocations to avoid them.

bscphil 5y ago
> 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.

bscphil 5y ago

> 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.