Slashdot Mirror
Building Distributable Linux Binaries?
Grubby Games asks: "I make games for a living, and I want to ensure that my games will run on as many Linux distros as possible. However, since I distribute binary game executables, the programs often fail to run on certain distros because of missing dependencies, and so forth. So, how do the Slashdot Linux gurus handle this situation? I've heard a number of theories on the subject, but have yet to find one that results in 100% cross-distro compatibility. Is it even possible, short of distributing source code?"
It can't be done with dynamic linking, despite what the Autopackage people tell you. There's too much variety between distributions with things like libc and libstdc++ versions. There's even too much variety between distribution releases in many cases.
Most distributions don't aim to provide binary compatibility between releases. Even RedHat get sick of shipping multiple copies of libraries eventually... And if you throw distributions like Gentoo into the mix, anything binary-based using dynamic linking is out of the question.
If you really must distribute binaries, static link them and distribute the associated libraries too. Assuming, of course, that said libraries' licences don't prohibit this -- for open things you're fine, but for obnoxiously licenced code (like your own) you're short of luck. Also note that you can't legally do this with LGPLed libraries (nor GPLed, of course).
*shrug* Of course, any respectable Linux user won't use your software unless they can see the code anyway. How else do we know it's not chock full of security holes and spyware?
Not the only way, there is also statifier
From the page:
Statifier create from dynamically linked executables and all it's libraries one file. This file can be copied and run on another machine without need to drag all it's libraries.
The entire point of having dynamically linked libraries is to have one central source to update your libraries at, and to share that functionality with other programs. If you are going to include the dynamic library with the program, it's easier to just make a statically linked executable...
But you can't statically link LGPL licensed libraries...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
Even that doesnt necessarily work if C++ is involved and the system its built on and the one its run on have different GCC & libstdc++ versions with different incompatible ABIs...
Mike
"Not an actor, but he plays one on TV."
You can do a few different options, each with their own drawbacks. Depending on the libraries you are currently using you will possibly have to use a combination of these items.
Static linking allows you to distribute a single binary that will run on any linux system so long as you have the correct minimum kernel version and CPU. Some of the problems with this will include the license on the libraries you are using may not allow this, and the application's code image changes from what you have debugged against.
Dynamic linking and putting all of the required dynamic libraries your application requires in their own personal library directory. This is the quickest solution, but not always the best solution. It does allow you to release periodic incremental patches to the binaries used by your applicaton.
Usage of a application such as Elf Statifier to take your debugged dynamic application, and bundling the applicable libraries into your application. This is a halfway point between a completely dynamic and static application that allows you to take your "GOLD" release and package it up without changing the generated code in your application.
Just release your application as a dynamic application and mark it with the correct dependancies in RPM format and follow the Linux Standards Base.
Most commercial applications will use either the 2nd method (dynamic and distribute all their own versions of various dynamic libraries) or the 4th method. In both cases they specify a message to the effect of "We support X distro version Y. It may work on your linux distro, but we only support X version Y."
As you are planning to make money off of this game, I wish you luck, and suggest you take a look into what the most popular linux distros for your target audience will be. Based on advertisements from Wal-Mart and Fry's selling Linux preloaded I would bet Linspire and Xandros is high on that list. As with all things, don't forget the testing across many distributions to make sure the solution you choose actually works.
The program isn't debugged until the last user is dead.
autopackage is probably the current best tool for this. It makes a single, easily installable (and removable) package while coercing my system's GCC and libs into versions that are suitable for other distributions.
:)
I use it currently for schism tracker (particularly the CVS builds that I do).
It works very well for me: Debian, Ubuntu, SUSE, Fedora, Gentoo, and Mandrake users have reported success with these binaries built with (gasp) a lone FC4 machine.
One day, I'll actually do a proper release and six years later it'll show up in the next Debian release. Then your fancy apt-get tools will work.
And to kneejerk jackasses that say "just release the source"- you must realize that the source is good for you and me (well me anyway, I cannot speak for you, obviously), the people who USE these programs have absolutely NO INTEREST in doing the work that I have just done for my own purposes.
Plus, having them use a single binary means that it's very easy to debug with nothing more than a core file.
Oh, and I suppose I am giving the submitter the benefit of the doubt that we are indeed talking about Free Software, aren't we?
As someone who is involved in supporting commerical closed-source applications on 3 Windozes, 5 Linuxes and 4 Solarises, I must confess - binary compatibility on Linux is too damn hard.
Solaris is way better than Linux in that regard, everything compiled on lower versions always works like a breeze on higher versions. Windows has a clear dividing line between retarded 95/98/ME and 2000/XP/2003/Vista, but we do not support 95/98/ME anyway, so binary compatibiity on Windows is wonderful, aside from some minor glitches with missing DLLs.
Now, binary compatibility on Linux is a total pain in the butt. Incompatibilities in glibc 2.2 vs 2.3, pthreads vs nptl, gcc C++ ABI is broken on every other gcc release, thread local storage, just to name a few hurdles.
Distributing statically linked executables is the most reliable way to go, if you want to support as many Linux variants as possible. However, there are few things to remember:
* If your application is security-critical, you link against static library and later security flaw is found in the library, OS security update leaves your application vulnerable.
* Never link statically with libdl. For example, application, statically linked on RH 7.3 witl libdl will misteriously crash on RH9
* Size of executables is big. Even worse if you have many executables using same libraries.
Oh, you said you are going to market games... Boy, you are better to build them for Windows anyway. Don't let me be misunderstood, I love Linux (except, for its binary (in)compatibility, of course), but it's just not the right market and business model for you anyway.
If you keep insisting on Linux, here is a hint. Most commercial vendors shipping products for Linux are oriented towards a limited number of distros, those used in enterprises. RedHat and SuSE that is. Mandriva? Ha-ha-ha. Oh, you say, Ubuntu and Debian are popular? Ouch, not among our cutomers.
my sstream of consciousness
"Usually?" How many games have you made, sir? Where is your data?
Meanwhile, here is a list of paid-for engines which you might have heard of, that get lots of money thrown at them from software developers:
This doesn't even take into account the specific engines, such as Havok, or engines of past that have made their parent companies TONS of money, such as the myrid of engines created by id and Epic. They DO have value. Maybe not to the end user, but they DO have value to the developers who otherwise creating these games would be a bigger chore than need be. These engines prevents developers from having to re-invent the wheel, for sound code, graphics code, physics, etc., every time they create a game.
He even said specificly "Is it even possible, short of distributing source code?". He clearly does not want to distribute his source, for one reason or another.
I'm the guy with the unpopular opinion