That’s what we do in DROD, and it’s worked perfectly so far. There’s been
a few version incompatibilities in the libs we use (various buggy Freetype
versions, SDL 1.2.8 capping surface height at 16384, etc), but none of
this was ever a problem since the game use the supplied libraries, not the
system ones.
There’s one big gotcha if you do this, though: RPATH. If you include
libraries with rpath set, your included libraries will be ignored and
the system-installed library is used instead. Many libraries (including
SDL!) compile with rpath set to /usr/lib by default, and it’s not always
straightforward to disable this. Be prepared for some libtool and
Makefile editing.
Once you’ve got some usable libraries included with your game, that still
requires the game to be run through a wrapper script, though. Currently
the DROD wrapper script sets LD_LIBRARY_PATH, but some time ago I
discovered that it’s possible to set RPATH for executables as well as
libraries, which removes the need for setting LD_LIBRARY_PATH at all.
It’s possible to set relative executable rpaths, but these are relative to
the current directory, not the executable directory … so you end up
needing that wrapper script anyway, unless you restrict installing to one
location (bad idea) or link at install time (requires object or
partially-linked files and a compatible linker). Might as well just use
LD_LIBRARY_PATH, then (which would also let people who really know what
they’re doing be able to edit it, which could be both a pro and a con …).
There is another way, though: dlopen. If you don’t mind having function
pointers for everything, you could make your executable search for the
libraries in stead, and load them dynamically at runtime from wherever you
stashed them.
One thing I’ve been thinking about occasionally is that it could even be
possible to statically link one version of SDL into your game and,
depending on configuration options, optionally override the statically
linked SDL with a dynamically loaded one, by setting those function
pointers accordingly. I’ve never actually done this, but I don’t see any
reason why it wouldn’t work, and I think it’d even be in compliance with
the LGPL without giving away any object files (since it allows relinking)
… although I admit this sounds like a “having your cake and eating it
too” scheme, and I don’t know what Sam would think of this what with the
new commercial licensing and all. (Sam ?)
- GerryOn Tue, 11 Jul 2006 00:56:59 +0200, Peter Mulholland wrote:
Our future policy, should we ship any further titles, will be to build
our own SDL and SDL_mixer and ship these with the game, in the same dir
as the game, and set up the link options so that the first path tried
for shared libs is the current dir. If there are issues with our shipped
libs, the user can remove them/symlink them as necessary.