It doesn't help that the Linux ecosystem makes it really difficult to build truly portable truly native binaries.
Static builds? Well, that will work... But wait, you want OpenGL or Vulkan? You'll need a dynamic linker to load system .so's, as that's the standard API available to interact with these APIs on Linux. Want to load dynamic libraries? Well, you'll need to ship a dynamic ELF [1]. Shipping a dynamic ELF with glibc now? Hope you don't intend to run on NixOS or Alpine or any distribution that has an old glibc. Maybe also ship ld-linux.so, all of /lib you depend on and a wrapper shellscript that sequences startup accordingly via that ld-linux.so. That will work, but you still need to load the system OpenGL or Vulkan .so's. Have fun implementing that to work well on every distribution! Remember to respect terms of GPL/LGPL software you now ship. Oh, and I hope you don't use Qt.
Maybe you want to use flatpak? Well, better explain to your users that they need to install and configure it, and make sure whatever proprietary Nvidia drivers they have are also properly flatpak'd. What about the alternatives, something like AppImage/Snap? Those just don't work on Alpine and other non-glibc distributions. Whoops.
Pick an audio API. Pulseaudio? Some people don't run it. ALSA? Good luck, some people run Pulseaudio with ALSA emulation disabled. OSS? Dead, unless someone runs padsp. Pray your users don't run JACK. You'll probably end up on OpenAL, which is now proprietary and/or has an LGPL fork (remember you now have to let users re-link against any other version of OpenAL!).
I sometimes make games and other small interactive demos. I run Linux, and want to send builds to friends also running Linux. The easiest way to distribute these is to build and ship a .exe on a Windows build host and get my friends to run it on Wine, that just works everywhere out of the box. And the .exe's end up smaller and launch faster, too!
Static builds? Well, that will work... But wait, you want OpenGL or Vulkan? You'll need a dynamic linker to load system .so's, as that's the standard API available to interact with these APIs on Linux. Want to load dynamic libraries? Well, you'll need to ship a dynamic ELF [1]. Shipping a dynamic ELF with glibc now? Hope you don't intend to run on NixOS or Alpine or any distribution that has an old glibc. Maybe also ship ld-linux.so, all of /lib you depend on and a wrapper shellscript that sequences startup accordingly via that ld-linux.so. That will work, but you still need to load the system OpenGL or Vulkan .so's. Have fun implementing that to work well on every distribution! Remember to respect terms of GPL/LGPL software you now ship. Oh, and I hope you don't use Qt.
Maybe you want to use flatpak? Well, better explain to your users that they need to install and configure it, and make sure whatever proprietary Nvidia drivers they have are also properly flatpak'd. What about the alternatives, something like AppImage/Snap? Those just don't work on Alpine and other non-glibc distributions. Whoops.
Pick an audio API. Pulseaudio? Some people don't run it. ALSA? Good luck, some people run Pulseaudio with ALSA emulation disabled. OSS? Dead, unless someone runs padsp. Pray your users don't run JACK. You'll probably end up on OpenAL, which is now proprietary and/or has an LGPL fork (remember you now have to let users re-link against any other version of OpenAL!).
I sometimes make games and other small interactive demos. I run Linux, and want to send builds to friends also running Linux. The easiest way to distribute these is to build and ship a .exe on a Windows build host and get my friends to run it on Wine, that just works everywhere out of the box. And the .exe's end up smaller and launch faster, too!
[1] - Or go for hacks like https://github.com/pfalcon/foreign-dlopen