Insanely topical now for the Steam Deck release! Tons of people online arguing about linux ports while not knowing what even goes into packing a game and what the dependencies that could break actually are. This is pretty good to get a feel for the issues here and not to just guess
How is this superior to flatpack? If I am shipping a game, it probably has a few gigs of assets. So shipping libraries etc is no issue. No fumbling with linker needed. Or am I missing something?
@@lepidoptera9337 If you prefer that to warthunder, flightgear, 0AD and zero-k, then sure, of course, linker is your main problem. There are plenty of really good games for Linux if you only look for them.
You don't have to discover the linker path at runtime. You can just run the linker directly and give the executable path as the first agument. For example /lib64/ld-linux-x86-64.so.2 ./test.exe. test.exe has a invalid path to linker, so on it's own it won't run, but running it like this works. With that in mind, you could write a simple bash script that will discover the linker path and call it with your game as a first argument.
Yep, but what he's trying to do is to not require extra code in the bin or a bash script. Just put the files in a standard place or alias to them or something. Not a rocket science ask.
I feel like musl distros and nixos are tiny niches inside the tiny niche that linux already is. Like the yellow part in the graph inside the yellow part of the graph. Just like running windows Just Works for gamers, running glibc distros (other than nixos) Just Works for gamers too, these days, as Steam and other releases of games for linux show. And for applications, AppImages fill the same niche. Again, leaving out musl distros and nixos. Cool demo either way though; if these barriers can be removed so that there are no hoops to jump, it's a win.
@26:13 the creator of RenderDoc doesn't approve me initializing it after my engine already started (but before touching LWJGL/OpenGL), but I do it anyways 😁. Much more comfortable starting it in my IDE than having it to start from within RenderDoc.
I must disagree about the Wayland part. Relying on Xwayland forever is not a solution - at least not in case we are actually try to make the switch happened. By now, apart from Gnome that worked that around a little bit (still far from perfect though), Xwayland cannot handle HiDPI on most compositors and by now it seems like it's won't fix, no one is actively working on it and the discussion is sort of stuck. Yes, it's fine when you just have a single screen and you work without changing screen density. High resolution displays are becoming more and more common, so that's a mess, really.
It's just a pain in the arse to make your software multi distro compatible. This problem just doesn't exist with Windows or macOS (for the most part). And let's face it: the Linux user experience sucks. So both groups, users and developers, have good reasons to prefer Windows and macOS.
Hah, fails on my Linux by endlessly trying to discover the linker path. I just get endless rows of debug: detecting whether we are running in the dynamic linker debug: we're not. detecting the dynamic linker path debug: prepare to execve reload debug: dyld_path=/lib64/ld-linux-x86-64.so.2 debug: setting environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0' debug: detecting whether we are running in the dynamic linker debug: we're not. detecting the dynamic linker path debug: prepare to execve reload debug: dyld_path=/lib64/ld-linux-x86-64.so.2 debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0' to 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' debug: detecting whether we are running in the dynamic linker debug: we're not. detecting the dynamic linker path debug: prepare to execve reload debug: dyld_path=/lib64/ld-linux-x86-64.so.2 debug: changing environment variable 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' to 'LD_PRELOAD=libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0 libdl.so.2 libpthread.so.0' And the LD_PRELOAD grows endlessly with repeats of the same two libraries. If I try to run it via ld-linux manually I get a different error: $ /lib64/ld-linux-x86-64.so.2 static-window9 static-window9: error while loading shared libraries: static-window9: cannot open shared object file As an aside, wouldn't the best solution be to work on a universal non-GNU loader that can be used by all distros? By non-GNU I mean it is not part of the GNU project itself, so there's no conflict of interest.
