Support us on Patreon
PayPal
I posed a question on Twitter recently where I asked developers to jump in with thoughts on essential things to know about when bringing a game to Linux. Let’s look over some answers!
In this article I will go over a few useful answers, giving full credit to the person who sent it in with a link to the tweet they sent to us. I will then give my own thoughts on each point, with any relevant links to help. There's likely hundreds of things we could point up, but these are what I consider to be some of the more common and important issues to keep in mind.
Some of the answers made me laugh, let’s start off with a good old joke about Arch Linux (source):
I enjoy a good poke about distributions here and there, but it’s actually very true. Of all the distributions there are, Arch does end up being the most problematic. That's not saying Arch is bad, but being on the edge (it gets newer software faster than most other distributions) obviously increases the amount of issues that are likely to come up, since it's had less time in the oven to work out issues.
Test on Ubuntu and if you can, SteamOS too. If it doesn't work on other distributions, they likely have workarounds as they are likely doing something different. Do not feel the need to test every distribution around, it will be impossible and it's just not needed, don't overthink it. Don't be afraid to limit support to the main bigger distributions either. Some people may not like the idea, but it's too much work for little gain most of the time. Support the big distributions, forget the rest (at least until you're much more familiar with Linux).
One from David Gow (source):
It doesn't necessarily need to be SDL2, there's also SFML and likely others. The point is, projects like that can make your life a lot easier. You might be wanting to keep everything small, but these projects are bigger for a reason, as they cover tons of edge cases and nuisances you likely haven't even thought of.
There's a reason why Valve, Feral Interactive, Humble Indie Bundle and many others use SDL2 for the Linux ports. Heck, even the Unity game engine moved over to use SDL2 in Unity 5.6.
This next one comes from none other than Timothee Bessett, formerly of id Software (source):
I think this is an important point for any developer to remember. Linux users want your game to do well, we will often help you test for free, because we want to help. Any time I’ve seen a developer call for Linux testers, they end up getting overwhelmed with the amount of people willing to offer their free time to help out. Opening up a private beta to a few select people is always an option too, there's many ways to get users involved early.
However, this is not a replacement for your own testing! Linux is free to download and use forever, it can be installed by itself or along side Windows & Mac. You can install it inside a virtual machine too if you want to just give it a look over.
This little tidbit comes from Holarse Linux-Gaming, our German friends (source):
This in particular is something I’m keen for developers to know about. Please, for the love of my sanity, don’t put a plain folder of “Game Name” inside my home directory. If you want to know where to store config files and saved games, you can find more info here.
As an example, Unity games tend to be in /home/user/.config/unity3d. Notice the dot before “config”, it’s a hidden directory so it doesn’t pollute a user's home directory and fill it to the brim with random folders.
Another one from Holarse Linux-Gaming (source):
You likely know what this means, but in case you don't: "This" is not the same as "THIS" when it comes to filenames on Linux. A crash in a game that's absolutely bugging you? Check you're looking for the right filename. This single issue has tripped up a lot of developers I've personally spoken to.
Let’s break things up with another amusing one, this time from a Feral Interactive developer (source):
I would be lying if I said this didn’t make me laugh quite a lot. You think some bug reports you got from Windows were weird enough? Prepare yourself.
The same Feral Interactive developer also put forward probably one of the most important points possible (source):
The amount of times we’ve seen developers announce a Linux port, be it on Steam’s old Greenlight platform, Kickstarter or wherever else, only to announce much later they can’t do it due to something they use being Windows-only is quite staggering. Check early and often that the tools, middleware and whatever else will be able to work somehow on Linux. Don't get stuck in the professionally embarrassing position where you have to u-turn on platform support.
Asking for help is not embarrassing and should not be seen as any kind of weakness, if you put out a call for help finding replacements or getting something to work on Linux, you might be surprised to find people able to help out quite often. I've seen hundreds of developers chatting away on Twitter, Reddit and other sites giving out help and advice about Linux issues.
Another one from a Feral developer (source):
The amount of times I've seen developers put up builds where they talk about knowing nothing about Linux: how do you expect to fix bugs in it, if you don't know the first thing about the platform? A little early research and testing will go a long way. The terminal might seem a little scary at first, but from someone who doesn't consider himself even remotely smart: just do it! Learn it and you might find a new friend. Still scared? This site might help you with the basics of the Linux command line.
If you plan to release your game outside of Steam and you want to use a handy installer, take a look at MojoSetup. GOG, the well known game store actually use this for their Linux releases.
An important point I would like to also raise: don't expect Linux sales to make you rich. It's a smaller platform. Bringing a game to Linux isn't just about getting sales from the additional platform, you should also keep in mind all of us likely know people on Windows & Mac we will end up recommending the game to, especially if it has any form of multiplayer. The extra advertising through various Linux websites and the extra word of mouth can be useful.
If you're wondering whether you need to make a 32bit build of your game, in my honest opinion you don't need to bother. 64bit only is fine especially since our own statistics tell us out of 1921 people who answered about their distribution, only 1 person is on a 32bit distribution.
Also, please don't take loud and idiotic users to heart. All communities will have trolls and haters, please do ignore any you find.
If you're trying to port to Linux and you're stuck, don't fret! Take a breath, come have a chat. We have a Forum, our Email inbox is always open, we have an IRC channel, Discord and more.
Finally, if you are considering bringing your game to Linux — thank you, can't wait to try it!
Please do share any other general tips you have in the comments. Article taken from GamingOnLinux.com.
In this article I will go over a few useful answers, giving full credit to the person who sent it in with a link to the tweet they sent to us. I will then give my own thoughts on each point, with any relevant links to help. There's likely hundreds of things we could point up, but these are what I consider to be some of the more common and important issues to keep in mind.
Some of the answers made me laugh, let’s start off with a good old joke about Arch Linux (source):
QuoteIf you are getting completely impossible and weird bugs that is almost impossible to reproduce, check if they are running Arch Linux…
I enjoy a good poke about distributions here and there, but it’s actually very true. Of all the distributions there are, Arch does end up being the most problematic. That's not saying Arch is bad, but being on the edge (it gets newer software faster than most other distributions) obviously increases the amount of issues that are likely to come up, since it's had less time in the oven to work out issues.
Test on Ubuntu and if you can, SteamOS too. If it doesn't work on other distributions, they likely have workarounds as they are likely doing something different. Do not feel the need to test every distribution around, it will be impossible and it's just not needed, don't overthink it. Don't be afraid to limit support to the main bigger distributions either. Some people may not like the idea, but it's too much work for little gain most of the time. Support the big distributions, forget the rest (at least until you're much more familiar with Linux).
One from David Gow (source):
QuoteUse SDL2. Or use something which itself uses SDL. Under no circumstances write X11 code directly.
It doesn't necessarily need to be SDL2, there's also SFML and likely others. The point is, projects like that can make your life a lot easier. You might be wanting to keep everything small, but these projects are bigger for a reason, as they cover tons of edge cases and nuisances you likely haven't even thought of.
There's a reason why Valve, Feral Interactive, Humble Indie Bundle and many others use SDL2 for the Linux ports. Heck, even the Unity game engine moved over to use SDL2 in Unity 5.6.
This next one comes from none other than Timothee Bessett, formerly of id Software (source):
QuotePlayers want you to succeed with your Linux release. Get them involved, for instance have them test stuff up for you.
I think this is an important point for any developer to remember. Linux users want your game to do well, we will often help you test for free, because we want to help. Any time I’ve seen a developer call for Linux testers, they end up getting overwhelmed with the amount of people willing to offer their free time to help out. Opening up a private beta to a few select people is always an option too, there's many ways to get users involved early.
However, this is not a replacement for your own testing! Linux is free to download and use forever, it can be installed by itself or along side Windows & Mac. You can install it inside a virtual machine too if you want to just give it a look over.
This little tidbit comes from Holarse Linux-Gaming, our German friends (source):
QuoteFor your files and savegames there is XDG (like %approot% on windows
This in particular is something I’m keen for developers to know about. Please, for the love of my sanity, don’t put a plain folder of “Game Name” inside my home directory. If you want to know where to store config files and saved games, you can find more info here.
As an example, Unity games tend to be in /home/user/.config/unity3d. Notice the dot before “config”, it’s a hidden directory so it doesn’t pollute a user's home directory and fill it to the brim with random folders.
Another one from Holarse Linux-Gaming (source):
QuoteYes linux filesystems ARE case sensitive
You likely know what this means, but in case you don't: "This" is not the same as "THIS" when it comes to filenames on Linux. A crash in a game that's absolutely bugging you? Check you're looking for the right filename. This single issue has tripped up a lot of developers I've personally spoken to.
Let’s break things up with another amusing one, this time from a Feral Interactive developer (source):
QuoteSomeone WILL play your game on their work render farm, and report the bugs [..] I'd be lying if I said this had only happened once. 128 cores!? 1TB RAM!?
I would be lying if I said this didn’t make me laugh quite a lot. You think some bug reports you got from Windows were weird enough? Prepare yourself.
The same Feral Interactive developer also put forward probably one of the most important points possible (source):
QuoteUse cross compatible tools whenever and where ever, anything can turn into a crutch when you try and port
The amount of times we’ve seen developers announce a Linux port, be it on Steam’s old Greenlight platform, Kickstarter or wherever else, only to announce much later they can’t do it due to something they use being Windows-only is quite staggering. Check early and often that the tools, middleware and whatever else will be able to work somehow on Linux. Don't get stuck in the professionally embarrassing position where you have to u-turn on platform support.
Asking for help is not embarrassing and should not be seen as any kind of weakness, if you put out a call for help finding replacements or getting something to work on Linux, you might be surprised to find people able to help out quite often. I've seen hundreds of developers chatting away on Twitter, Reddit and other sites giving out help and advice about Linux issues.
Another one from a Feral developer (source):
Quoteembrace the shell, the sooner the better. The last thing you want 2 hours before release is to be fumbling around learning bash
The amount of times I've seen developers put up builds where they talk about knowing nothing about Linux: how do you expect to fix bugs in it, if you don't know the first thing about the platform? A little early research and testing will go a long way. The terminal might seem a little scary at first, but from someone who doesn't consider himself even remotely smart: just do it! Learn it and you might find a new friend. Still scared? This site might help you with the basics of the Linux command line.
If you plan to release your game outside of Steam and you want to use a handy installer, take a look at MojoSetup. GOG, the well known game store actually use this for their Linux releases.
An important point I would like to also raise: don't expect Linux sales to make you rich. It's a smaller platform. Bringing a game to Linux isn't just about getting sales from the additional platform, you should also keep in mind all of us likely know people on Windows & Mac we will end up recommending the game to, especially if it has any form of multiplayer. The extra advertising through various Linux websites and the extra word of mouth can be useful.
If you're wondering whether you need to make a 32bit build of your game, in my honest opinion you don't need to bother. 64bit only is fine especially since our own statistics tell us out of 1921 people who answered about their distribution, only 1 person is on a 32bit distribution.
Also, please don't take loud and idiotic users to heart. All communities will have trolls and haters, please do ignore any you find.
If you're trying to port to Linux and you're stuck, don't fret! Take a breath, come have a chat. We have a Forum, our Email inbox is always open, we have an IRC channel, Discord and more.
Finally, if you are considering bringing your game to Linux — thank you, can't wait to try it!
Please do share any other general tips you have in the comments. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Mountain Man 5 Jul 2017
Learning bash has the second advantage of being helpful on Mac also.If only for the purposes of transferring large number of files from one location to another. I've found the OSX GUI often chokes on the process making the command line the only reliable method for getting it done.
0 Likes
I am German and there are a lot of games that have a problem with comma being the decimal point in my locale. Often enough, even recent Unity games, save floating point data locale independent and parse them locale dependent, leading to crashes, bugs, and corrupted saves.
It's easy enough. Just use Double.Parse with the current locale as separate parameter. It's not magic. I think I've added LC=C_ALL as a environment variable to about half of all Steam games I play.
Same here, I'm French and for quite a lot of games (at least 10 / 20% I had to add LANG=C before the command to launch the game. Examples include Anna Extended edition, and so on. Most of the affected titles are indie.
Same here , i'm Turkish and i'm suffering this LC_ALL=C problem.
Even i filed a report on Steam Github about that and i also discovered Danish and Russian users are suffering from that too. Even some Greek user was suffering from that problem on GoL too.
https://github.com/ValveSoftware/steam-for-linux/issues/4792
Steam Client is only properly working on an US English or UK English locale.
1 Likes, Who?
Learning bash has the second advantage of being helpful on Mac also.If only for the purposes of transferring large number of files from one location to another. I've found the OSX GUI often chokes on the process making the command line the only reliable method for getting it done.
Off-topic, but ironically, this is also true on Windows, especially for long path names on network locations (cygwin, cmd or powershell, it doesn't matter; but the windows shell won't do it sometimes, at least on 7).
0 Likes
Same here , i'm Turkish and i'm suffering this LC_ALL=C problem.Same for Russia. Especially if you run a game while switched to the russian layout. It brings all sorts of weirdness such as non-working keys (partially or fully) or inability to rebind them. It doesn't even depend on the LANG variable and happens in many games. Unfortunately, most of the games are made by english-speaking folks that don't have secondary layouts to test the game against. I don't expect this to change so I have to adapt to it myself and anyway almost always translations suck, I prefer the original language. After the initial issues with locales in Steam I ended up switching to en_GB.UTF-8 system-wide (as I said, translations suck, including the system software ones) and setting english layout as default. There are also issues with the input method, namely iBus that's default on Ubuntu and Unity/Gnome DEs. At least in couple of games it brings keyboard issues like stuck or non-working keys. After switching to plain XIM it all goes away:
Even i filed a report on Steam Github about that and i also discovered Danish and Russian users are suffering from that too. Even some Greek user was suffering from that problem on GoL too.
https://github.com/ValveSoftware/steam-for-linux/issues/4792
Steam Client is only properly working on an US English or UK English locale.
export GTK_IM_MODULE=xim
export QT_IM_MODULE=ximDespite the var names it affects not only GTK/Qt software but also games.
1 Likes, Who?
I think developers ought to use LANG=C (en_US-UTF8 might not be installed) in their startup scripts if they don't plan to test and support multiple locales the right way.
I think games and programs should use keycode rather than keysym internally for keybindings. Keybindings like shift+semikolon might not work if it is defined as keysym, because semicolon on norwegian qwerty is shift+comma already. If it was shift+keycode 47 instead then it would work on norwegian qwerty too, although it would be shift+ø instead of shift+semikolon. Definitely show the keybindings to the user as keysym though. To differentiate KP_7 and KP_HOME(numpad) a bit of keysym is needed as well.
I think games and programs should use keycode rather than keysym internally for keybindings. Keybindings like shift+semikolon might not work if it is defined as keysym, because semicolon on norwegian qwerty is shift+comma already. If it was shift+keycode 47 instead then it would work on norwegian qwerty too, although it would be shift+ø instead of shift+semikolon. Definitely show the keybindings to the user as keysym though. To differentiate KP_7 and KP_HOME(numpad) a bit of keysym is needed as well.
2 Likes, Who?
I think developers ought to use LANG=C (en_US-UTF8 might not be installed) in their startup scripts if they don't plan to test and support multiple locales the right way.Oh, that's for sure. Overall, Linux unicode support in games is lacking. I'm always suprised to find a working russian chat in a game because usually trying to type in non-latin layout results in:
I think games and programs should use keycode rather than keysym internally for keybindings.
- displaying empty spaces instead of chars: Factorio in en locale because the default font only contains basic ASCII set, works fine in ru locale or after manually overriding the font in the data files; recently even that has been broken and fixed after my report;
- garbage: Rust and Unity-powered games in common, in Rust it shows some random arabic letters and squares though I can read russian messages of other players;
- or just nothing at all: Natural Selection 2 a year or two ago (works just fine these days) or Dying Light last time I checked.
It saddens me more sometimes as the game actually can display unicode properly but the unicode input is broken in some way. So I feel like a dog understanding everything but being unable to answer (without resorting to translit or plain english). It's worse though if unicode is broken completely so I neither can read nor write. Can't suggest anything to the devs as I'm no expert in XInput/SDL quirks, and there sure are many.
Also, that doesn't apply to me directly as we don't have such things in russian, but many west-european folks (French, German) say that diacritics are often broken as well. But they at least have a big set of ASCII chars that's sufficient to write with. There are also combining diacritics that are added to a base character and a wide range of eastern languages with wildly combining characters (see hindi for example). Supporting THAT is a serious challenge on any platform though.
1 Likes, Who?
I would recommend building under the previous Ubuntu LTS version, so for example at the moment it would be Ubuntu 14.04.
That's a bad advice, since it severely limits compiler features. I don't think anyone should worry about supporting previous LTS of major distros.
Last edited by Shmerl on 5 Jul 2017 at 6:10 pm UTC
0 Likes
I partially disagree. I think you should at least wait 6 months, maybe a year from an LTS is released until you start compiling against the new one unless you have a good reason, like using features of the newest C++ version not available in the older LTS.I would recommend building under the previous Ubuntu LTS version, so for example at the moment it would be Ubuntu 14.04.
That's a bad advice, since it severely limits compiler features. I don't think anyone should worry about supporting previous LTS of major distros.
0 Likes
Looks like you haven’t followed the discussion. The point is to support most distros actually in use by using an "old" glibc and libstdc++. Also, no, it does not "severely limit compiler features".
Not sure how you can achieve that. If you use some older libstdc++ you can't for example use new features like C++14 and etc. I.e. you should expect that something as old as LTS older than the current one, won't have some language features. That limits what you can use.
That said, you can simply use Rust, and forget about woes of libstdc++ ;)
Last edited by Shmerl on 5 Jul 2017 at 8:58 pm UTC
0 Likes
Philadelphus 5 Jul 2017
Paradox should unstick their head from the sand, and fix the engine. I suspect their general neglect to make their tools 64-bit compatible, forced Obsidian to release Tyranny in 32-bit only (because it used Paradox account integration libraries). It created the expected mess of lacking LFS and crashes on large XFS partitions. The bottom line - no excuses. 64-bit is a must today. (Luckily Obsidian finally released 64-bit version of Tyranny this June).Ah, interesting. I've only heard it from Paradox's side and wasn't aware of the problems you mentioned. I guess I'm less informed on the matter than I thought
Some engines have a lot of work to make them 64-bit, and understandably it can take time. But not doing it at all with excuse that performance is OK as is, is just silly. Beamdog for the reference reworked their current generation of Inifinty engine to 64-bit.
Oh, I'm fully in agreement that it doesn't make sense to make two builds. And I'm not actually a 32-bit apologist or anything, I'm just discovering I've been misinformed—so thanks for the info.Serious question, are there actually that many 64-bit executable games out there and is it actually beneficial?
I don't believe the argument is really one of how much benefit 64 bit has over 32 bit. Rather, it's an argument of how beneficial is it to ship both 64 bit and 32 bit builds. If you're writing your own engine from scratch, it's quite a waste of time to make sure it's 32 bit compatible on Linux, just make it 64 bit.
1 Likes, Who?
Bottom line.
https://twitter.com/PirateHearts/status/879239978290642945
https://twitter.com/PirateHearts/status/879239978290642945
3 Likes, Who?
There may very well be good reasons for making games 64-bit and I've love to hear them, it's just that I tend to see 64-bit thrown around as a bit of a buzz-word.
Another advantage of 64 bit builds is more registers, which might make some things faster. But if they are far from needing 4 GB, a port of their engine to 64 bits might actually not be worth it. (And depending how well it was implemented, possibly long ago, it might be hard.) There's no magical performance doubling or something along the lines.
Last edited by Eike on 6 Jul 2017 at 7:56 am UTC
1 Likes, Who?
Awesome! You can't write too many of these articles! Keep them coming and I'll never stop supporting this site! ;)
0 Likes
I remember one game where the developer had a Unity3D game running within a day, but had dependency problems when starting from the Steam runtime.STASIS is suffering from this right now. The engine needs newer libstdc++.so.6 than provided in SteamOS so it doesn't start there. So another advice: check your dependencies on older distros if possible and either ship the libs with the game or link them statically if you can.
Actually this is a very specially sad case. SteamOS supplies 6.0.20 but the Steam runtime supplies the 6.0.21 version that STASIS requires so the problem with STATIS is that it doesn't use the Steam runtime but the system one and that Valve somehow messed up their own distribution by supplying an older version for the OS than what they themselves support via their runtime.
For STASIS it should work on SteamOS if they changed their start script to look in the Steam runtime path for libraries before looking at the system path.
0 Likes
Great article Liam,
One of my worries for Linux is how should developers code their programs and place all their folders and files so that 5 years down the line with newer hardware, kernel and distro and any updates associated, it can still be guaranteed that our purchased software will still be forward/backwards compatible and run? I personally find it annoying when your system is running fine for 2 years or so and just works, then have to do an update to the latest distro to get game x to work just to find you have to hunt down and figure out how to install xyz library or package to get an old game or software running again.
I'd like to point out that the community is great generally and with a little googling and patience one generally finds answers to solve your problems, for myself I guess I should save all those sources of help and index them all in a text file of sorts.
I second this. Usually this can be achieved by NOT STATICALLY LINKING the libraries (which is one of the reasons to have them in the first place). The libraries get updated (especially if they are open source), and make the games run in their new environment. This is why LGPL/zlib2 (iirc) is such a great thing :)
2 Likes, Who?
Great article Liam,
One of my worries for Linux is how should developers code their programs and place all their folders and files so that 5 years down the line with newer hardware, kernel and distro and any updates associated, it can still be guaranteed that our purchased software will still be forward/backwards compatible and run? I personally find it annoying when your system is running fine for 2 years or so and just works, then have to do an update to the latest distro to get game x to work just to find you have to hunt down and figure out how to install xyz library or package to get an old game or software running again.
I'd like to point out that the community is great generally and with a little googling and patience one generally finds answers to solve your problems, for myself I guess I should save all those sources of help and index them all in a text file of sorts.
I second this. Usually this can be achieved by NOT STATICALLY LINKING the libraries (which is one of the reasons to have them in the first place). The libraries get updated (especially if they are open source), and make the games run in their new environment. This is why LGPL/zlib2 (iirc) is such a great thing :)
Most libraries will break with major updates, so you should bundle almost all your dependencies. But there are some libraries that should not be bundled, you should just use what the system provide instead. This page was not updated for a long time but it's still relevant: https://freegamedev.net/wiki/Portable_binaries#System_libraries_that_cannot_be_bundled
I worked on a company that developed OpenGL applications and using this approach we were able to build on CentOS 5 and run on Ubuntu 16.10, for example. That's 9 years of backward compatibility.
1 Likes, Who?
I worked on a company that developed OpenGL applications and using this approach we were able to build on CentOS 5 and run on Ubuntu 16.10, for example. That's 9 years of backward compatibility.
How much work was it to follow all security problems, update the statically linked binaries and ship them for nine years...?
0 Likes
Only an issue if the software "faces out" as it were. You're assuming this isn't something that just simply runs on the computer; not everything has to be networked.I worked on a company that developed OpenGL applications and using this approach we were able to build on CentOS 5 and run on Ubuntu 16.10, for example. That's 9 years of backward compatibility.
How much work was it to follow all security problems, update the statically linked binaries and ship them for nine years...?
0 Likes
Most libraries will break with major updates, so you should bundle almost all your dependencies. But there are some libraries that should not be bundled, you should just use what the system provide instead. This page was not updated for a long time but it's still relevant: https://freegamedev.net/wiki/Portable_binaries#System_libraries_that_cannot_be_bundled"Bundling" can be interpreted differently form statically linking, though. I usually agree with "bundling"/providing the shared libraries along with the executable (and maybe a LD_LIBRARY_PATH "hack" in a launcher script), but not with static linking.
I worked on a company that developed OpenGL applications and using this approach we were able to build on CentOS 5 and run on Ubuntu 16.10, for example. That's 9 years of backward compatibility.
The only "valid" reason I can think of for statically linking executables is to distribute your program as only one binary. But even then, there are better options (sfxs, flatpack-like files with an embedded filesystem image or archive), and it only concerns a very nice portion of all applications (usually, portable ones).
Link time optimization and other optimizations are another reason it could be useful, but that's not true in practice (and ld can perform lto on shared objects as well, IIRC).
But yes, carefully pick the libs you bundle. To me, the general rules are:
- Libs everyone have (double check everyone *is* everyone). Don't bundle them, dynamically link.
- Libraries provided by a third party as part of a special contract with your studio/company: provide them as .so
- Internal libraries developed by your studio/company: statically link them, perform a monolithic compilation with them or provide them as .so depending on your needs or update/modding/debug policy
- Relatively common libraries that are well maintained: provide them with a .so, but prefer the ones on the system (query ld folders, add them to LD_LIBRARY_PATH, then add the folders they are in to LD_LIBRARY_PATH, essentially what Steam is doing)
- "wild" libraries that are not very well maintained, or can break the API (early development version, for instance): avoid them, you will probably run into problems a few years down. If you must use them, provide them, don't statically link them but prefer them to the host libraries. That way, you make it possible to tinker with them if it stops working, but they should work the same way regardless of the system.
- Prefer open source libraries whenever possible (still avoid the previous case): generally well maintained, people can fix them easily if they are broken a few years down the line, or write wrappers for them in the worst case.
- Whenever possible (and that's usually a more general software rule), avoid complex dependencies. Both for the libs you choose (they should depend on a minimum of other libraries) and for your application. Bonus points if you can enable/disable some dependencies via a config file (though you may have to manually load your libraries. It's not *that* complicated, and as a bonus, you can gracefully fallback and disable features)
Do you agree with those, or would you change/add something?
1 Likes, Who?
You had a fair share of valid points (I especially agree with the very last one), but I read your post as being quite aggressive, and it seems that I have been misunderstood multiple times. So there goes the counter-multiquote.
I don't think I understood this correctly. What shouldn't be required?"Bundling" can be interpreted differently form statically linking, though. I usually agree with "bundling"/providing the shared libraries along with the executable (and maybe a LD_LIBRARY_PATH "hack" in a launcher script), but not with static linking.
Shouldn't be required if symbol versions are used.
I am not sure statically linking actually reduces risks at all (it doesn't prevent code injection at all, but just raises the difficulty a bit). It can also be a security risk, because you then statically linked libs with CVEs in them, and no mean to upgrade them (especially if the developer doesn't care anymore, which is unfortunately often the case).The only "valid" reason I can think of for statically linking executables is to distribute your program as only one binary. But even then, there are better options (sfxs, flatpack-like files with an embedded filesystem image or archive), and it only concerns a very nice portion of all applications (usually, portable ones).
Security. How secure depends entirely on the attack surface of course but in general preload is easier then binary editing.
I didn't mean it that way. What I meant is that you had to provide them (but preferably as shared objects, so that they can be upgraded later by the consumer, if you care about your consumer, that is ;) )But yes, carefully pick the libs you bundle. To me, the general rules are:
- Libs everyone have (double check everyone *is* everyone). Don't bundle them, dynamically link.
- Libraries provided by a third party as part of a special contract with your studio/company: provide them as .so
Redistribution rights may prohibit it.
The difference here is that if that's *your* IP, *you* are the one who is going to update it. Contrast this to the case where ex. Valve releases a steamaudio fix. If they do, the customer can upgrade the .so (that's done transparently trough Steam, usually). If that's your lib, you will probably release an update to the game when you update the lib (if you are a good guy). Of course, this is only useful when the company producing the game goes downhill, and that's not the use case most companies care most about.Internal libraries developed by your studio/company: statically link them, perform a monolithic compilation with them or provide them as .so depending on your needs or update/modding/debug policy
Don't quite see the difference between this and above. If it's not public IP, there's no reason not to protect it.
Avoiding poorly maintained libraries is an invitation to disaster? Come on, tell me you didn't say this just to contradict me. Breaking the ABI/API is ok when the library is well versioned. That way, the system can provide the different versions, or compatibility shims."wild" libraries that are not very well maintained, or can break the API (early development version, for instance): avoid them, you will probably run into problems a few years down. If you must use them, provide them, don't statically link them but prefer them to the host libraries. That way, you make it possible to tinker with them if it stops working, but they should work the same way regardless of the system.
Invitation to disaster. There are MANY libraries that aren't backward compatible. Pulse for example. Simply including or not including doesn't negate other dependencies elsewhere.
I must confess that I didn't really get your sentence.Prefer open source libraries whenever possible (still avoid the previous case): generally well maintained, people can fix them easily if they are broken a few years down the line, or write wrappers for them in the worst case.
Bit irrelevant. There are quite open source libraries that are not backward compatible and outright refuse to run otherwise. Pulse, dbus, etc.
As far as I know, the linker has to link every dependency at runtime, before even starting to execute the program. You have to dlopen() if you want to handle complex feature toggling.Whenever possible (and that's usually a more general software rule), avoid complex dependencies. Both for the libs you choose (they should depend on a minimum of other libraries) and for your application. Bonus points if you can enable/disable some dependencies via a config file (though you may have to manually load your libraries. It's not *that* complicated, and as a bonus, you can gracefully fallback and disable features)
Also a bit irrelevant. The linker has no problems resolving dependencies. There is a bit of overhead at runtime though.
0 Likes
How to set, change and reset your SteamOS / Steam Deck desktop sudo password
How to set up Decky Loader on Steam Deck / SteamOS for easy plugins
See more from me