3 ms·

Im not sure why Vulkan keeps being raised here: Steam/proton demonstrate that windows developers aren't interested in Vulcan either, it's directx or bust, and t

by olliej 4y ago

Im not sure why Vulkan keeps being raised here: Steam/proton demonstrate that windows developers aren't interested in Vulcan either, it's directx or bust, and then "supporting" linux is just done via Wine. If Steam/proton aren't going to work for Mac any time soon as they're fundamentally "run a x86 windows game in a translator", and as far as I can make out wine requires 32bit hardware to emulate the win32 environment (also, why do windows devs who ostensibly care about performance but still ship 32bit binaries?).

pengaru 4y ago
> Im not sure why Vulkan keeps being raised here: Steam/proton demonstrate that windows developers aren't interested in Vulcan either, it's directx or bust I think you're making some rather broad assumptions about why developers aren't targeting Linux natively vs. relying on WINE/Proton being a lack of interest in Vulkan. The major complaint I see from Windows game developers WRT supporting Linux is the still insane situation of shipping executables for Linux userspace as it exists today. The first challenge everyone encounters attempting it is that glibc overtly doesn't support static-linking. That renders practically every mainstream linux distro largely incapable of even producing statically-linked executables utilizing external dependencies. Go ahead, try it. Arch Linux doesn't even install the .a files of every library it has .h and .so files installed for. Arch literally goes out of its way to strip them from packages. Even if you do manage to stay within a small enough set of deps to succeed, gcc will spit out warnings about static linking being unsupported due to stuff like nsswitch. The whole exercise is immediately maddening and discouraging, and everything you see screams RUN AWAY. Game developers already target myriad graphics APIs simply from shipping on consoles as well. There are already GL libraries to hide such annoyances if you're not determined to eek out every last bit of GPU performance. The instant Proton/WINE became a reliable way to ship binaries for every linux distro under the sun that Just Work, most developers abandoned even figuring out how to build equivalent native linux binaries. It's so crazy you can actually more successfully produce statically-linked Windows and MacOS binaries of an SDL2+SDL2_Mixer et al using game, on Linux, via mingw and osxcross toolchains, than you can produce equally statically-linked Linux executables, from within linux, if attempting to use the distro-provided libraries. I'm a long-time Linux user+developer, as FOSS/Linux/GNU-biased as you'll find, and even I will shout from the rooftops THIS IS INSANITY. The new shiny way to paper over this embarrassment is containers; a host-like instance full of dynamically linked dependencies per executable! Brilliant.
- david2ndaccount 4y ago
  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.
andrewmcwatters 4y ago
This is not true. Vulkan is still the preferred option for game developers moving from OpenGL 3.3/4.0+.

by olliej 4y ago

pengaru 4y ago

> Im not sure why Vulkan keeps being raised here: Steam/proton demonstrate that windows developers aren't interested in Vulcan either, it's directx or bust I think you're making some rather broad assumptions about why developers aren't targeting Linux natively vs. relying on WINE/Proton being a lack of interest in Vulkan. The major complaint I see from Windows game developers WRT supporting Linux is the still insane situation of shipping executables for Linux userspace as it exists today. The first challenge everyone encounters attempting it is that glibc overtly doesn't support static-linking. That renders practically every mainstream linux distro largely incapable of even producing statically-linked executables utilizing external dependencies. Go ahead, try it. Arch Linux doesn't even install the .a files of every library it has .h and .so files installed for. Arch literally goes out of its way to strip them from packages. Even if you do manage to stay within a small enough set of deps to succeed, gcc will spit out warnings about static linking being unsupported due to stuff like nsswitch. The whole exercise is immediately maddening and discouraging, and everything you see screams RUN AWAY. Game developers already target myriad graphics APIs simply from shipping on consoles as well. There are already GL libraries to hide such annoyances if you're not determined to eek out every last bit of GPU performance. The instant Proton/WINE became a reliable way to ship binaries for every linux distro under the sun that Just Work, most developers abandoned even figuring out how to build equivalent native linux binaries. It's so crazy you can actually more successfully produce statically-linked Windows and MacOS binaries of an SDL2+SDL2_Mixer et al using game, on Linux, via mingw and osxcross toolchains, than you can produce equally statically-linked Linux executables, from within linux, if attempting to use the distro-provided libraries. I'm a long-time Linux user+developer, as FOSS/Linux/GNU-biased as you'll find, and even I will shout from the rooftops THIS IS INSANITY. The new shiny way to paper over this embarrassment is containers; a host-like instance full of dynamically linked dependencies per executable! Brilliant.

david2ndaccount 4y ago
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.

andrewmcwatters 4y ago

This is not true. Vulkan is still the preferred option for game developers moving from OpenGL 3.3/4.0+.