I’d like to make a binary installer for a game I wrote on linux, this
game obviously use sdl 
I’m just wondering if there are some guides or tutorial about how to
perform the following steps, obviously I’ve googled around a few hours
before posting here, but with almost not useful results…:
No tutorials that I’m aware of. (I’ve been thinking about writing one,
though. I seem to be answering this kind of questions pretty often as
of late =))
- Obtain a compressed “clickable” installer that runs with almost any
libc version.
(loki installer + makeself?)
Loki+makeself works fine, but Loki is severely outdated. Autopackage
seems more up-to-date, but has some flaws like not being entirely self-
contained (you either need an internet connection at install time, or
more files) and no possibility of showing a README/EULA, etc. If you’re
not just interested in free stuff, I’ve heard good things about the
Bitrock installer. Loki is still the most feature-rich one, though.
But, as I said, outdated. Sigh.
Anyway, even if you get an installer you can live with, the “runs with
almost any libc version” might be trickier than you think. I guess it
depends on your audience, but imo supporting ancient glibc versions is
more trouble than it’s worth. I’ve settled for 2.3 and higher myself,
which is still old-ish (2.3 came out in 2002 sometime, I think), and
doesn’t require too many hacks to get working. In any case, there’s
basically two ways to do this:
- Use an old glibc when linking.
Should be simple, right ? Unfortunately old glibcs doesn’t compile with
newer gccs. There are ways around this (google for crosstool), but you
might still run into compatibility issues. I used to do this with DROD,
but have now moved on to…
- Use a newer glibc, but prevent linking with too new symbol versions.
Unfortunately there’s no options you can pass to gcc to make it do this
the easy way. In stead, you’ll have to override the symbols manually
using assembler directives. This is a bit of a hack, but it seems to
work. Autopackage has some tools that can help with this (see
http://autopackage.org/aptools.html), or you can use a similar tool
I made that generates a similar header for you in a somewhat different
way (http://delirare.com/files/gensymoverride). Once you’ve got your
header, you can include it as the first argument to gcc when compiling
stuff, using the -include option. That’ll give you glibc compatibility,
but remember that you’ll have to compile any libraries you include this
way as well. And the installer, if you compile that.
Also, try to make the libraries you include as compatible as possible.
To stray on-topic a bit, for SDL you’ll want to include support for arts,
esd and alsa so that people will get sound no matter what they use, but
you don’t want to require these libraries since not all of them are
installed everywhere. Thankfully SDL supports run-time dynamic linking
for this purpose, which you can enable in configure. You might also
want to include as many video drivers as you can without adding more
dependencies. Also, using the -Wl,–as-needed switch when linking
(with newer gcc’s) will make sure that only libraries that are actually
used directly by what you link are required. Nice to get rid of that
spurious SDL libstdc++ dependency that pops up sometimes. (Using this
might make dependencies you need to include harder to spot if you’re
just using ‘objdump -x file | grep NEEDED’. Use LD_LIBRARY_PATH with
ldd on the executable as well).
Do NOT statically link glibc. Don’t include it in your installer either.
Get rid of libgcc_s.so with -static-libgcc. If your game is C++, you can
link libstdc++ statically (this is actually required in addition to using
-static-libgcc if you want to statically link libgcc with C++ code), but
doing this means exceptions won’t work correctly across dynamically linked
files. Rule of thumb is, if you’re statically linking libstdc++, you
should statically link everything that uses libstdc++ into the same
file. To statically link libstdc++ properly, get the .a location with
’g++ -print-file-name=libstdc++.a’ and pass this as the final argument
when linking.
- Be able to add KDE / Gnome menu entry in the correct way.
(no idea at all about this, I’ve seen that many distributions place the
small xml file used to describe the menu entry in different places, also
the format is slightly different in kde & gnome…, freedesktops may
helps?)
Well, it depends how old distributions you want to support. Loki Setup,
for example, does things the old way, which still kinda works, but menu
entries tend to get lumped into the “Other” menu in stead of Games on
some newer systems. Going with the freedesktop.org standards is a better
idea these days. It obviously won’t work on systems that came out before
the standards were in widespread use (which should at least be a couple
years ago by now ?), but it’ll work correctly on what’s out there today.
http://www.freedesktop.org/wiki/Standards/desktop-entry-spec
http://www.freedesktop.org/wiki/Standards/menu-spec
http://www.freedesktop.org/wiki/Standards/basedir-spec
- Be sure that the game uses my libraries and not the ones provided on
the user machine (to avoid compatibility issues).
(export LD_LIBRARY_PATH=./mylibs:$LD_LIBRARY_PATH in the game startup
script is enough?)
Usually, yes, assuming the shell supports the export command, you’re in
the right current directory when executing the game, the libraries are
built correctly, and that the libraries in ./mylibs does not contain
any RPATHs, since libraries with RPATH won’t work in any other locations
than the one specified in their RPATH. You can check for RPATH with
objdump -x. If any libraries has it set, you need to remove it somehow
(the easiest way is to just rebuild them after fixing the config and/or
makefiles or libtool).
Btw, you can also use RPATH on the executable to specify the location
of the libraries in stead of using LD_LIBRARY_PATH. If you use an
absolute rpath, you don’t need the wrapper anymore, but on the other
hand you’ll only be able to install the libraries in one hard-coded
location (= bad) unless you modify the executable at install-time…
The alternative is a relative rpath, but that still requires the
current directory to be set correctly, so you’ll need the wrapper
again. The LD_LIBRARY_PATH way is more convenient.
Well, that was a bit of an overview, at least. Hope it helps =)
~ GerryOn Fri, 01 Dec 2006 09:40:27 +0100, Gabriele Greco <gabriele.greco at darts.it> wrote: