4 ms·

macos doesn’t support statically linking to libsystem.dylib (equivalent of glibc) and windows doesn’t have a static version of kernel32.dll. The problem isn’t d

macos doesn’t support statically linking to libsystem.dylib (equivalent of glibc) and windows doesn’t have a static version of kernel32.dll. The problem isn’t dynamic vs. static linking, it’s that linux distros don’t offer backwards compatibility (although the linux kernel does). The whole static vs dynamic arguments people make is so weird to me, as what real apps do is ship the dlls/frameworks they need alongside the executable.

pengaru 4y ago
I've personally shipped some small cross-platform games for win+macos+linux, and it's rather trivial to produce the statically-linked versions for windows and macos even from within Linux. When the experience you encounter attempting the same thing for the linux build is an actively developer-hostile environment the moment you attempt to shove -static in your LDFLAGS and --static in your pkg-config flags, the message seems rather loud and clear: "We don't want you easily shipping standalone proprietary binaries on our systems avoiding learning and using our package management machinery!" It's rather desirable to hand out standalone executables for such simple isolated programs as games. Your claim that games don't statically link when possible strikes me as rather odd. It's such a common practice that SDL added an escape hatch to divert SDL calls to another libSDL at runtime [0]. Because sometimes you want a newer SDL to fix/support some newfangled stuff, and not be stuck with the statically linked version. Do you really think the SDL devs would bother with such a thing if it weren't a common practice? [0] https://github.com/libsdl-org/SDL/blob/release-2.26.2/src/dynapi/SDL_dynapi.c#L403 https://github.com/libsdl-org/SDL/blob/release-2.26.2/src/dy...
- david2ndaccount 4y ago
  You can statically link SDL2 itself, but you are still dynamically linking to libsystem, Cocoa and a collection of other dynamic libraries provided by the system. Same thing on Windows, you are dynamically linking to user32.dll and other libs. And why wouldn’t you anyway? The system actually offers backwards compatibility for those dynamic libraries. Given that you already have to have a dynamically linked executable, the difference between static linking your libraries vs. just shipping dlls alongside the executable is academic. It’s just another resource the program needs to run. Common practice on linux does make this needlessly difficult - you have to fiddle with things like RPATH so that your libraries don’t try to load from system libraries with no backwards compatibility guarantee.

pengaru 4y ago

I've personally shipped some small cross-platform games for win+macos+linux, and it's rather trivial to produce the statically-linked versions for windows and macos even from within Linux. When the experience you encounter attempting the same thing for the linux build is an actively developer-hostile environment the moment you attempt to shove -static in your LDFLAGS and --static in your pkg-config flags, the message seems rather loud and clear: "We don't want you easily shipping standalone proprietary binaries on our systems avoiding learning and using our package management machinery!" It's rather desirable to hand out standalone executables for such simple isolated programs as games. Your claim that games don't statically link when possible strikes me as rather odd. It's such a common practice that SDL added an escape hatch to divert SDL calls to another libSDL at runtime [0]. Because sometimes you want a newer SDL to fix/support some newfangled stuff, and not be stuck with the statically linked version. Do you really think the SDL devs would bother with such a thing if it weren't a common practice? [0] https://github.com/libsdl-org/SDL/blob/release-2.26.2/src/dynapi/SDL_dynapi.c#L403 https://github.com/libsdl-org/SDL/blob/release-2.26.2/src/dy...

david2ndaccount 4y ago
You can statically link SDL2 itself, but you are still dynamically linking to libsystem, Cocoa and a collection of other dynamic libraries provided by the system. Same thing on Windows, you are dynamically linking to user32.dll and other libs. And why wouldn’t you anyway? The system actually offers backwards compatibility for those dynamic libraries. Given that you already have to have a dynamically linked executable, the difference between static linking your libraries vs. just shipping dlls alongside the executable is academic. It’s just another resource the program needs to run. Common practice on linux does make this needlessly difficult - you have to fiddle with things like RPATH so that your libraries don’t try to load from system libraries with no backwards compatibility guarantee.