4 ms·

Static linking has been such a nuisance for the libSDL folks that they implemented dynamic loading of itself [0], controlled via an environment variable, as an

Static linking has been such a nuisance for the libSDL folks that they implemented dynamic loading of itself [0], controlled via an environment variable, as an escape hatch from executables w/libSDL linked statically. It's understandable that games, especially proprietary ones, distribute statically-linked binaries ensuring any third-party dependencies will be present and be a compatible version. But the value of that decision tends to diminish with time, as those external dependencies are frequently the pieces interfacing with the system/outside world, which keeps changing, leaving such dependencies behind to atrophy at best or become vulnerable/incompatible/broken at worst. I don't personally think it makes sense to approach this so dogmatically. Static linking makes sense in the right circumstances, so does dynamic linking. For general-purpose operating systems, it seems obvious to me that you'd want most higher-order userspace programs dynamically linked. I want my openssl updates to touch a single library and affect all installed ssl-using programs, for example. Having said that, I do wish the average linux distro still statically linked everything in /bin and /sbin. It was nice to still be able to administrate the system even when the dynamic libraries were hosed. At some point it was changed to just a single static binary; sln for static ln IIRC, assuming you'd be able to fix your dynamic libraries with some symlinks if they were broken, if you happened to have a shell running and could navigate using just builtins. It was already an impossible situation, but even that seems to be gone nowadays. It's a more nuanced issue, taking an "everything dynamically linked!" or "everything statically linked!" approach strikes me as just another form of ignorant extremism. [0] http://hg.libsdl.org/SDL/file/2fabbbee604c/src/dynapi/SDL_dynapi.c#l292 http://hg.libsdl.org/SDL/file/2fabbbee604c/src/dynapi/SDL_dy...

jart 6y ago
There's nothing wrong with taking a principled approach to builds. For example, it's not just a question of static or dynamic. Linking of vendored/static/pinned/etc. sources/artifacts/etc. in general comes with the benefit of hermeticity. That enables tools to work better, since it gives them perfect knowledge of the things that exist. It also entails a certain degree of responsibility for writing your own scripts that can generate automated alerts should issues arise in the upstream sources.
cryptonector 6y ago
> [...] Having said that, I do wish the average linux distro still statically linked everything in /bin and /sbin. It was nice to still be able to administrate the system even when the dynamic libraries were hosed. [...] This argument came up back when Solaris 10 was in development and the project to get rid of static link archives for system libraries came up (search for Solaris "unified process model"). The disposition of this argument was that if your libraries are damaged (e.g., someone unlinked them or renamed them out of the way, or maybe ld.so.1 itself), well, the dependent utilities in /bin and /sbin themselves could have been damaged too, so you can't know the extent of the damage, and it's not safe to continue -- you have to use boot media to repair the damage, or reinstall. And, of course, the packaging system has to be safe, but that's not a lot to expect of a packaging system (is it??). To my knowledge there were no subsequent customer calls about this.
- jart 6y ago
  Sometimes solutions give rise to new categories of issues, and it's difficult to connect the dots to the root cause. If you believe dynamic linking hasn't introduced an even broader array of difficulties for C coders needing to support both, then please read Ulrich Drepper's DSO tutorial which gives a pretty good rundown: https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf https://software.intel.com/sites/default/files/m/a/1/e/dsoho... If I remember correctly, it was largely SCO Group that pushed UNIX vendors back in the 1990's to switch to a WIN32 linking model. I didn't find their arguments that compelling, to be honest, due to not citing alternatives considered.
  - lokedhs 6y ago
    Unrelated told your post, but please don't suggest that SCO Group was involved. The company in the 90's was simply SCO, and was a pretty cool company. SCO Group was renamed as such from Caldera in the early 00's and was the people suing Linux users for copyright infringement.
  - pjmlp 6y ago
    Dynamic linking was already common outside UNIX (Amiga, Xerox, Atari, MacOS, MS-DOS overlays and extenders, IBM and Unisys mainframes, Oberon/Lilith) so what does Win32 even have to do with it?
account42 6y ago
It's really a decision you have to do per-library. For something like SDL that has a stable ABI while providing user-visible improvements in newer versions, dynamic linking makes sense. SDL's solution isn't only for static linking but also for bundled dynamically loaded SDL copies. I am not really convinced that SDL's approach is perfect though as anyone statically linking SDL can just disable this functionality and this feature has already caused problems requiring you to manually substitute the loaded libSDL. For libs that don't interact with the system, dynamic linking does not really provide an advantage for binaries that are distributed on their own.

jart 6y ago

There's nothing wrong with taking a principled approach to builds. For example, it's not just a question of static or dynamic. Linking of vendored/static/pinned/etc. sources/artifacts/etc. in general comes with the benefit of hermeticity. That enables tools to work better, since it gives them perfect knowledge of the things that exist. It also entails a certain degree of responsibility for writing your own scripts that can generate automated alerts should issues arise in the upstream sources.

cryptonector 6y ago

> [...] Having said that, I do wish the average linux distro still statically linked everything in /bin and /sbin. It was nice to still be able to administrate the system even when the dynamic libraries were hosed. [...] This argument came up back when Solaris 10 was in development and the project to get rid of static link archives for system libraries came up (search for Solaris "unified process model"). The disposition of this argument was that if your libraries are damaged (e.g., someone unlinked them or renamed them out of the way, or maybe ld.so.1 itself), well, the dependent utilities in /bin and /sbin themselves could have been damaged too, so you can't know the extent of the damage, and it's not safe to continue -- you have to use boot media to repair the damage, or reinstall. And, of course, the packaging system has to be safe, but that's not a lot to expect of a packaging system (is it??). To my knowledge there were no subsequent customer calls about this.

jart 6y ago
Sometimes solutions give rise to new categories of issues, and it's difficult to connect the dots to the root cause. If you believe dynamic linking hasn't introduced an even broader array of difficulties for C coders needing to support both, then please read Ulrich Drepper's DSO tutorial which gives a pretty good rundown: https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf https://software.intel.com/sites/default/files/m/a/1/e/dsoho... If I remember correctly, it was largely SCO Group that pushed UNIX vendors back in the 1990's to switch to a WIN32 linking model. I didn't find their arguments that compelling, to be honest, due to not citing alternatives considered.
- lokedhs 6y ago
  Unrelated told your post, but please don't suggest that SCO Group was involved. The company in the 90's was simply SCO, and was a pretty cool company. SCO Group was renamed as such from Caldera in the early 00's and was the people suing Linux users for copyright infringement.
- pjmlp 6y ago
  Dynamic linking was already common outside UNIX (Amiga, Xerox, Atari, MacOS, MS-DOS overlays and extenders, IBM and Unisys mainframes, Oberon/Lilith) so what does Win32 even have to do with it?

account42 6y ago

It's really a decision you have to do per-library. For something like SDL that has a stable ABI while providing user-visible improvements in newer versions, dynamic linking makes sense. SDL's solution isn't only for static linking but also for bundled dynamically loaded SDL copies. I am not really convinced that SDL's approach is perfect though as anyone statically linking SDL can just disable this functionality and this feature has already caused problems requiring you to manually substitute the loaded libSDL. For libs that don't interact with the system, dynamic linking does not really provide an advantage for binaries that are distributed on their own.