Distributing a game on Linux

[Jebbs]

Hey guys!

I finally got SFML running under Linux! It took some doing, but I feel pretty accomplished. I'm definitely not a Linux user at all.
Anyways, I was curious about how one would go about getting a SFML program running on other Linux machines. Do they need to install the SFML dev package like I did? Or will it just run on their system(given they are compatible distros) with out anything going wrong? I was reading on the forums earlier and saw that static linking on Linux isn't the best idea. Why is that? Wouldn't it be a good thing if all they had to do was run the application and not have to install anything on their system?

This is something I've always wondered so any insight would be awesome!


Thanks in advance!

[TheVirtualDragon]

I believe that sfml-dev is only required if you're compiling from source, because then you need the actual header files etc. and you don't need the development package if you are just playing the game. I think there is a normal sfml package in Synaptic (Debian/Ubuntu/Mint etc.) which does not include development files but I am not sure because I compile SFML from source (in fact, I compile most things from source on linux - it's much more fun ). I am not sure about the static linking, but lots of people do it anyway. Whatever Windows can do, Linux can do it for free.

[TomCatFort]

Most distributions only provides packages for stable releases, so SFML 2.0 RC won't be in the repos. But!

Linux uses the ELF format for executables, and this particular format supports the embedding of shared object search paths. These paths can be relative or absolute.
The linker can take any number of this paths separately using the -R% parameter, where the % is the path. But if you use g++ as the linker / final step, then it's a little different as you have to tell g++ that you have a linker specific parameter. You do this using the -Wl,$ parameter where the $ are linker parameters separated by comas.
This way you can distribute your game alongside the needed dynamic libs just like in Windows.

Here is an example:

g++ -Wl,-R. -o mygame main.cpp

This will make mygame search for libs in the same directory where it is placed. You can check this with the ldd command.

[pdinklag]

I have one question related to this, kind of. If I was to distribute JSFML (Java binding), I would love to hide away all binaries (.so on Linux) inside the jar file itself.

This works fine, but the question is: are the binaries compatible to all possible Linux distributions? How can I tell which they are compatible to?

I build them on Ubuntu 12.04, which is Debian based. So I am fairly certain that it will run on all Debians with the same or newer kernel version (?), but what about a SUSE, just for instance?

[Laurent]

are the binaries compatible to all possible Linux distributions? How can I tell which they are compatible to?

They should be compatible with all the distributions (but you still need to have separate 32/64-bit versions, of course). Every Linux uses gcc, so there's no binary compatibility issue.

Of course you can still have problems with dependencies, users need to have all the required external libraries. You may also have a problem if a user has a binary-incompatible version of an external library, but this is unlikely to happen with the libraries used by SFML (which are all very old and stable).

If I was to distribute JSFML (Java binding), I would love to hide away all binaries (.so on Linux) inside the jar file itself.

Are you talking about your own libraries, or SFML ones?

[pdinklag]

Are you talking about your own libraries, or SFML ones?

Both, in fact. The binding itself and the SFML binaries it is compatible to.

I believe I cannot rely on a distribution's repository's current version of SFML to be compatible to the JSFML build I happen to release, so I believe it's better to pack it all up together where I'm sure it works.

This ensures the most flexibility for me and users won't have to worry about what SFML version is currently marked as "latest" in the distribution's repository. This also makes sure that developers can pack up JSFML in their releases and don't have to worry about an update breaking stuff.

Of course, this is not just about JSFML, but probably any application / game using SFML. For Windows, you'd pack up the DLLs with your app, so to me it makes sense to pack up the SOs for Linux and the whatevers for Mac. For "uncommon" libraries like SFML, I see the repositories maintained by Linux distributions more as an obstacle and possible source of problems than any kind of help.

So if these binaries, given they are linked against a commonly available version of glibc, are compatible to (probably) any Linux distro of the same architecture, is there any actual drawback of doing it this way?

[Laurent]

Once SFML 2.0 is released, it will shortly be part of the official distributions repositories, and most important, it will be stable and backward compatible. So providing your own build of it may cause more problems, in fact.

[mongrol]

Once SFML 2.0 is released, it will shortly be part of the official distributions repositories, and most important, it will be stable and backward compatible. So providing your own build of it may cause more problems, in fact.

"shortly" is a variable definition in this case. Debian Wheezy has now been frozen with 1.6 still in place. Derivative distro's (Ubuntu included) will need to package their own sfml 2.0 for it to be included. The maverick arch linux maintainer has had 1.99git included for over a year. Surely bundling the version you want to run is the safe option in this case?

[Qix]

I have one question related to this, kind of. If I was to distribute JSFML (Java binding), I would love to hide away all binaries (.so on Linux) inside the jar file itself.

This works fine, but the question is: are the binaries compatible to all possible Linux distributions? How can I tell which they are compatible to?

I build them on Ubuntu 12.04, which is Debian based. So I am fairly certain that it will run on all Debians with the same or newer kernel version (?), but what about a SUSE, just for instance?

As long as the .so is compatible by itself, then it will be compatible inside the .JAR. After all, a .JAR file is a zip file with a few header modifications and a new extension (no really, rename .jar to .zip. Works just the same).

The fact they're in a JAR makes no difference.