Building Distributable Linux Binaries? 128
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?"
Distribute source (Score:3, Funny)
Ah geeks..always finding a way to answer the question with a better(?) one.
Re:Distribute source (Score:4, Funny)
You forgot force the user to move to your distro of choice and I only play Nethack.
Re:Distribute source (Score:2)
We are more open minded then that. Most of us have also tried slash'em once or twice. :)
Re:Distribute source (Score:2, Insightful)
Re:Distribute source (Score:2)
And if Joe Noobie hoses his libc, qt _and_ gtk libs in an attempt to play a cheesey version of Hearts, well then the lesson is more va
Staticly link EVERYTHING. It's the only way. (Score:2)
Re:Staticly link EVERYTHING. It's the only way. (Score:4, Informative)
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.
Re:Staticly link EVERYTHING. It's the only way. (Score:5, Informative)
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.
Re:Staticly link EVERYTHING. It's the only way. (Score:2)
Kermit and distributed.net are examples of places where you can almost always find a binary for your system. Those might not be bad places to look to figure out what sorts of
Re:Staticly link EVERYTHING. It's the only way. (Score:2)
I've heard about this problem, but I don't recall whether it is due to a bug in glibc, or a bug in Redhat's many modifications. I just know I haven't run into any such problem in Slackware. I don't even touch Redhat anymore given so many issues like this.
Maybe you should do a survey of your Linux c
Use a virtual machine? (Score:2)
Ideas (Score:5, Interesting)
Java and Python are obvious. You can always use things like JNI and the Python-C bridge if you feel you need better speed in some parts. As long as those parts don't link to any external code, you won't have any problem. They are both very fast these days, and by using things like PyOpenGL and Java3D you can get accelerated rendering and everything. Plus you would only need one codebase for both windows, linux, and OS X.
As for a static build, you may or may not want to do that. The size of the executable will be much larger, and it will take more memory to run, but you won't have the problem of everyone has a different version. It would solve your problem.
As an odd suggestion: why not build all your code into objects and distribute those with a little script to link them on the client machine into an executable. That would fix the problem right? The problem is you couldn't strip the binary (if you do that) because the linker needs the symbols (right?). But it would solve you problem. This is my understanding of how nVidia's kernel drivers work (they have a little glue source too, which you could include). This way they don't have to put out a version for every combination under the sun.
I hope this helps. This is one area where Linux is (rather far) behind Windows and OS X. It's not much of a problem if you've got the source, but if the application is closed source (like yours) then it can be a headache. This is something that the LSB was trying to solve, but I don't know how far they got (or how many distros follow their guidelines).
Re:Ideas (Score:2)
That is a big if ;). Personally, I'd stay away from Python and use Java - Pythons nature (lack of data hiding, lack of strong typing) makes it very easy to have the program collapse into a horrendous mess. On the other hand, for proof-of-concept things and people with tempered steel disc
Re:Ideas (Score:1)
Re:Ideas (Score:2)
that's what I do :) (Score:2)
Re:Ideas (Score:2)
I package a GPLed Python application which requires 8 other Python libraries. Although users could run from source, they wou
Java and Python dependencies (Score:2)
Java on the other hand is Java. Unless you want to go the SWT route, if you are using Swing/Java2D, all the stuff is there.
Re:Java and Python dependencies (Score:2)
Errm, that isn't true except for trivial applications. A standard Linux box will not have all the many libraries used to run bigger Java applications. How do they print, how do they do databases, what about Hibernate, servlet containers etc
A good example is a finance manager. Look at how many libraries it needs:
With a program like Azu
Need J2EE for a game? (Score:2)
Re:Need J2EE for a game? (Score:2)
Disclaimer: I didn't actually look at the list so the "none of those" part might be wrong.
Re:Ideas (Score:2)
Nope. If it was that simple, it'd just work anyway. Problem is, if structures in header files or whatever change, then the old object files are no longer compatible with the new library, and a recompile is needed.
Not so hard (Score:3, Interesting)
For regular binaries, a static build is pretty much guaranteed to work. Alternatively, all Linux distributions I know of
Re:Ideas (Score:3, Interesting)
I have nothing against the Linux way, there is good stuff to say about it. But you if you want to compete, you can't go around saying "We're not windows so you can't criticize us for that." It is a very valid concern.
Maybe this is where some middle-man can make money. If they can cre
It's not possible. (Score:2, Informative)
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 o
Re:It's not possible. (Score:5, Insightful)
Ah. So that's why Loki went bust.
But you know what... I'm respectable, and I bought their games. And no, I didn't get any source code.
There are legitimate reasons not to release source code, and the original poster didn't give any details of his licence, so I think you're being excessively harsh to call it obnoxious.
The decision to distribute source code or not does not affect the quality of the software. It may make it harder for you to look inside, but remember - Sony didn't release their DRM source code either.
Re:It's not possible. (Score:2)
Nor did I, and that means that I have no hope of ever getting the bugs in Railroad Tycoon II fixed. (And that includes the one that makes the game crash if you want to play multiplayer. I wonder how they could not notice that before release.)
I, too, see the point in hiding the source code of games while they're new. But I would love for the law to require source to be released when a program is no longer actively maintained. And that will of
Re:It's not possible. (Score:2)
Re:It's not possible. (Score:1)
Re:It's not possible. (Score:2)
Dude, *we* aren't the only ones that tell you it can be done. The *users* also tell you it can be done. What more proof do you need?
"There's too much variety between distributions with things like libc and libstdc++ versions."
That is exactly why we have developed APBuild. We've done extensive research into finding out *why* glibc versions cause problems.
UT2K4 (Score:1)
Re:UT2K4 (Score:2)
Neverwinter Nights also packaged SDL to a subdirectory, and then had a wrapper script say "export LD_LIBRARY_PATH=./miles:./SDL-1.2.5:$LD_LIBRARY_PA TH" which worked fine and let the user update the libraries if needed.
Re:UT2K4 (Score:1)
Read this for more about why LD_LIBRARY_PATH is bad practise:
http://www.visi.com/~barr/ldpath.html [visi.com]
Re:UT2K4 (Score:2)
I'm sure you can. However, using a shell script and LD_LIBRARY_PATH allows the user to switch into using the systems default library if wanted. For example, I have a newer version of SDL installed than the one supplied with NWN, and NWN works pe
Re: (Score:2)
Re:UT2K4 (Score:3, Informative)
But you can't statically link LGPL licensed libraries...
huh?? (Score:3, Informative)
Mike
Re:huh?? (Score:1)
The LGPL only allows for dynamic linking without providing source, and the resulting application must allow the substitution of newer or improved or replacement version of the libraries you link to.
Personally, I'd question the need to use any sort of license if you just want to dynamically link - you're not using any of their code (assuming the header files
Re:huh?? (Score:3, Interesting)
Re:huh?? (Score:1)
I can see I'll have to read it again a few times. The GPL is easy enough to understand, but the LPGL kinda makes my head hurt.
Re:huh?? (Score:2)
compatibility with C libraries (Score:1)
Netscape 4.8 and Maple 5.0 have been compiled for libc5 and run on many systems.
I meant 2.3.4 (Score:1)
Re:compatibility with C libraries (Score:2)
Open Source Engine, Proprietary Data (Score:5, Insightful)
Re:Open Source Engine, Proprietary Data (Score:1, Interesting)
(ppffftttt) Milk just shot out of my nose (and I'm not drinking milk).
The real value of a game tends to be in the data files
Wipe the drool from your chin before posting, please. Do you know how brutally retarded you sound? Take any commercial game company. For example:
"John Carmack - your Doom 3 engine is merely a 'playback library', the real value here is in the 'data files' (snicker)".
"Rocksta
Re:Open Source Engine, Proprietary Data (Score:3, Informative)
Easy (Score:2, Funny)
Re:Easy (Score:2)
Re:Easy (Score:2)
2. Not enough, for high values of proprietary-ness, such as the case we are talking about, where the guy wants to distribute binaries that run by themselves.
--------
I'll use this to bitch about moderation.
I _do_ have karma to burn, but I really hate to see a +1, Funny , and then a -1, Overrated.
Nobody cares that you think something is not funny. Punishing people who get Funny ratings (This combination is a -1 karma penalty), even if they are not fun to you, ruins my experience. I like silly comments,
Half-Binary (Score:3, Interesting)
If you take this approach, be _very_ careful to have _everything_ that interfaces with the outside system in the open source part; I've worked with kernel modules where some OS calls were still made from inside the binary part, and they were hell.
Re:Half-Binary (Score:4, Informative)
Re:Half-Binary (Score:2)
control the whole show (Score:3, Interesting)
Re:control the whole show (Score:2)
Re:control the whole show (Score:2)
It's the same reason I don't use Linux. I would like to use Linux. I know Linux isn't a beginner system and there's a lot of work involved in making it behave smoothly and completely on a system, I'm not afraid of that. I'm an I/T worker (this supports my gaming habit). But I don't use it because I need to play games, lots of games, a
Re:control the whole show (Score:2)
I have two boxes under this desk, one Ubuntu Linux, the other XP... I have a KVM switch for swapping between them, so the flashy windows games are only a button click away, and I can leave one paused while getting on with real work on the Linux box...
Re:control the whole show (Score:2)
Binary Compatibility is an Illusion (Score:3, Interesting)
In a word, no. Binary compatibility just isn't. It happens to work in very select situations, usually on proprietary operating systems that are themselves binary-only, which means the developers of the OS would be dealing with the same headaches you would if they broke binary compatibility.
On Linux, where binary compatibility has very low priority because _everything_ on the system works fine without it, binary compatibility happens only by accident. It starts with the fact that Linux runs on many architectures, and people actually use it on most, if not all, of these architectures.
Then there are distributions that are still using libc5. Think they don't matter? What happens when libc7 comes out? And if you think that isn't going to happen for a long time, how about when X.org replaces the monolithic structure they inherited from XFree86 by their new, modular one? Or how about when Qt 4 replaces Qt 3, or GNOME 3 is released? These projects are not going to let themselves held back because of your app. Because this is what binary compatibility means: slowing progress, because some changes become impossible.
Re:Binary Compatibility is an Illusion (Score:2)
There are a couple of paths that proprietary OS's have taken to maintain binary compatibility. One approach taken by Apple and Sun is to thoroughly document what will be the stable ABI and maintain backwards compatibili
Binary Compatibility is a long-solved problem (Score:2)
A minimally necessary step is to label interfaces with what revision of what standard they use. The distributor then adds interfaces labeled "POSIX 20.3.6" (an imaginary standard) when the 3.6 release comes out. They don't remove the 20.2 stuff until no-one uses it any more (e.g., when they switch from 32 to 64-bit), and ELF apps link to the version they need.
If an application needs a newer version than 20.2, the user can
Re:Binary Compatibility is an Illusion (Score:2)
Static Linking (Score:1)
Re:Static Linking (Score:1)
This tactic is not legal under the LGPL. :-/
I think the Open Source engine, proprietary content game is probably the best way to go. Of all the kinds of software out there, games are the kind where I question the viability of the Open Source model the most.
Re:Static Linking (Score:2)
Unless the copyright holder(s) of the libraries agree to licence it under a different licence.
Neither the GPL nor the LGPL preclude the owner from make individual agreements with other parties.
Re:Static Linking (Score:1)
Re:Static Linking (Score:2)
Re:Static Linking (Score:2)
what you still have is the harddisk space issue, but considering the typical ratio of code vs media in games this won't be much of a problem either.
it would be a wholly different story in case of an IM client for example.
Re:Static Linking (Score:2)
Do you remember the zlib buffer overrun problem a while back?
So many appliactions statically linked to zlib had to be updated.
How about the jpeg buffer overrun where MS provided a program to search out all the office apps that were statically linked to the joeg library so they could patch.
I just thought I'd mention the downside.
sam
Re:Static Linking (Score:2)
And good on you for doing so. Everything is a trade-off.
Re:Static Linking (Score:2)
Would that be a "stupid" mistake? heh!
Sam
klick (Score:4, Insightful)
http://klik.atekon.de/ [atekon.de]
A couple of suggestions (Score:1)
I would probably set up an apt repository for Debian, where it's easy to make sure it works with the given dependencies. I would complement that with a statically linked rpm and plain old tarball.
Well, in actual fact I would also distribute it as FOSS, of course. I doubt that would impact your revenue negatively. Rather, the fact that people have the possibility to patch bugs and port it themselves would probably make them more willing t
Re:A couple of suggestions (Score:2)
Oh yes, because I see so much open source software making money on sales. More likely it would be copied and passed around on the p2p networks with no worries. I personally don't think games will ever do well as open source, to much capital has to be spent on development to allow anyone to give it away. You also would have massive cheats created for any network play which has killed several games.
Re:A couple of suggestions (Score:1)
How is that different from any other computer games, now?
chroot. (Score:1)
There are a few different options (Score:5, Informative)
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 [sourceforge.net] 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 [linuxbase.org].
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.
Re:There are a few different options (Score:2)
alien --to-deb blah.rpm
dpkg --install blah.deb
fun idea (Score:1)
How to kill Linux (as per Unix) (Score:4, Insightful)
Distributors who want to make it hard for you to run your binaries are every bit as wise as the Unix vendors who tried to avoid standardization and the risk of mutual success...
--dave
Re:How to kill Linux (as per Unix) (Score:1)
Software distribution model (Score:2)
Re:How to kill Linux (as per Unix) (Score:2)
And that's the root cause of DLL hell (:-)). Shipping down-rev libraries with applications and adding them to a the general LD_LIBRARY_PATH is something of bad thing.
Now, I'm sure you meant one should put them in a different place ad set the application's LD_LIBRARY_PATH or load path, but many Windows and some Unix folks do it the wrong way.
I admit I'm being grumpy, but it burns my ass when folks repeat the same mistake over and over again, expecting a different result. The library problem was solved
Re:How to kill Linux (as per Unix) (Score:2)
autopackage (Score:3, Informative)
I use it currently for schism tracker [rigelseven.com] (particularly the CVS builds [nimh.org] 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?
Re:autopackage (Score:2)
For the non-clickers among us:
Re:autopackage (Score:2)
That's like saying Firefox extensions are broken, because they might come from sites other than mozilla.org.
Re:autopackage (Score:2)
* Because the site may have been hacked?
* Because the package may have been downloaded from an untrusted mirror?
* Because the package may have came from an untrusted third party?
* Because the proxy server of your institution may be compromised?
Usually the distribution package checks a signature that is already trusted, either by a one time download of a key or by having being installed by the original cd-rom. The problem with runing a package to install it is th
But I still love SUSE 10 anyway... (Score:1)
HOWEVER, the catch is that the answer to the above question is not a unanimous "Yes, here's how and it'll work for most if not all distrobutions." Why? Too many variables to account for. To be almost universal across the linux distro, you'd have to release at least three different binarys (which at most covers a dozen or so of the most common distros). To make it completly universal across all linux distros, you'd have to release your source
Just program it to do that. (Score:2)
distribute the libs you need, except glibc (Score:2)
This pretty much guarantees compatibility across distributions. Just make sure the glibc you link against is old enough. Then just distribute binary tarballs and tell people only "glibc 2.2 or newer required" "glibc 2.3 or newer required" etc. It works pre
Been there, done that. (Score:2)
Enjoy,
How it works in an ideal world where LSB works... (Score:3)
If you are using libraries that the LSB does not specify, build private copies and distribute them in your package.
Good lord! That's pretty much exactly how software distribution works on Windows!
Remember STATIC linking? (Score:1)
We used to link EVERYTHING static and we had a stand-alone binary.
I miss the old days...we've got the resources for it...multi gig RAM, multi-multi gig hard disks, etc.
autopackage has been working on this stuff (Score:2)
another option is to build on the oldest distro you plan to target.
in any case there are two main issues with building distributable linux binaries
1: glibc symbol versioning
glibc uses a symbol versioning system that means builds made against a newer glibc not work with an older one.
2: macros in headers. e.g. if you use gtk 2.4 headers then your binary will end up relying on new gtk 2.4 featu
statically link with every dependency (Score:2)
What about Mono? (Score:2)
Assuming you *can* switch to Mono (and that's a really big "if" there), you could supply instructions for how to install Mono at your Web site for the common distros - it's simple for all Debian-based distros and for Gentoo, and probably RedHat/Mandriva/etc. as well. Alternately, you could (possibly|probably) ship Mono with your co
Re:You make games for a living? (Score:2)
a hardcore gamer might not want to play them, but for casual gamers, they look like they could be quite fun (if they're done properly).
Re:You make games for a living? (Score:3, Interesting)
Re:You make games for a living? (Score:1)