Custom libSDL dependencies inconsistent?

SDL Development
1

I apologize for the lack of brevity. I’ll try to summarize here, but the
rest should give context to what I am trying to do.

When I build a custom libSDL (1.2.11) using gcc-4.1 and configure
options to reduce dependencies, I get a library with reduced
dependencies but with a dependency on GLIBC_2.4, which prevents me from
using it on an older computer. When I use gcc-3.3, I can use it on an
older computer, but for some reason I have dependencies on libX11 and
libXext. Why does it configure differently just because CC is defined as
gcc-3.3? See output of configure below.

The details:
I’m trying to build a game for GNU/Linux, and since I want to make sure
that I don’t have to tell someone “But it works on my system!”, I’m
trying to bundle all needed libraries with the distributable binary.

In order to do so, I need to get rid of as many dependencies as I can so
the download will be as small as possible. I followed Troy Hepfner’s
tutorial on the subject at
http://www.gamedev.net/reference/programming/features/linuxprogramming2/page3.asp
which was great. I managed to reduce the dependencies to only a few
libraries, which I provided.

Except I had a problem. My dev system is Ubuntu 7.04, which uses
gcc-4.1, and so the binaries I produce depend on GLIBC_2.4, which would
be fine except people using older systems, like Debian Stable, couldn’t
run the game.

As I learned at http://trac.autopackage.org/wiki/LinuxProblems and other
places, this is a common issue. I asked for help at
http://happypenguin.org/forums/viewtopic.php?p=20401 and eventually
found that I could install gcc-3.3 on my system, which produced binaries
that didn’t depend on GLIBC_2.4.

But there was another problem. Now I see that libSDL depends on libX11
and libXext. I checked the output of configure, and here is the relevant
portion of the outut that I see if I use the following options:

OPTIONS="–prefix=$LIB_DIR --enable-X11-shared --disable-rpath
–disable-ipod --disable-video-directfb --enable-sdl-dlopen"

** If it is using the default gcc on my system, which is gcc-4.1:

checking for ESD - version >= 0.2.8… yes
– /usr/lib/libesd.so.* -> libesd.so.0
checking for NAS audio support… no
checking for X… libraries , headers
checking for gethostbyname… yes
checking for connect… yes
checking for remove… yes
checking for shmat… yes
checking for IceConnectionNumber in -lICE… yes
– dynamic libX11 -> libX11.so.6
– dynamic libX11ext -> libXext.so.6
checking for X11/extensions/Xrandr.h… no
checking for X11/extensions/dpms.h… yes
checking for framebuffer console support… yes
checking for PlayStation 2 GS support… no
checking for SVGAlib (1.4.0+) support… no
checking for libVGL support… no

** If I export CC=gcc-3.3:

checking for ESD - version >= 0.2.8… yes
– /usr/lib/libesd.so.* -> libesd.so.0
checking for NAS audio support… no
checking for X… libraries , headers
checking for gethostbyname… yes
checking for connect… yes
checking for remove… yes
checking for shmat… yes
checking for IceConnectionNumber in -lICE… yes
checking for X11/extensions/Xrandr.h… no
checking for X11/extensions/dpms.h… yes
checking for framebuffer console support… yes
checking for PlayStation 2 GS support… no
checking for SVGAlib (1.4.0+) support… no

Why is there a difference?–
GBGames’ Blog, An Indie Game Developer’s Somewhat Interesting Thoughts:
http://www.gbgames.com/blog
Staff Reviewer for Game Tunnel, the Independent Underground:
http://www.gametunnel.com

2

Gianfranco Berardi wrote:

I apologize for the lack of brevity. I’ll try to summarize here, but the
rest should give context to what I am trying to do.

When I build a custom libSDL (1.2.11) using gcc-4.1 and configure
options to reduce dependencies, I get a library with reduced
dependencies but with a dependency on GLIBC_2.4, which prevents me from
using it on an older computer. When I use gcc-3.3, I can use it on an
older computer, but for some reason I have dependencies on libX11 and
libXext. Why does it configure differently just because CC is defined as
gcc-3.3?

Of course I would find out why AFTER I spend a week trying to figure it
out and then emailing the list.

The changelog for libSDL:

SDL 1.2.11 Release Notes

SDL 1.2.11 is a minor bug fix release.
Unix Notes

 * Dynamic X11 loading is only enabled with gcc 4 supporting

-fvisibility=hidden. This fixes crashes related to symbol collisions,
and allows building on Solaris and IRIX.

Nice. Now it looks like I’ll need to find another way to get rid of
GLIBC_2.4 dependencies. I would rather update to the latest version than
drop back down to 1.2.10, though.

Thanks anyway. B-)–
GBGames’ Blog, An Indie Game Developer’s Somewhat Interesting Thoughts:
http://www.gbgames.com/blog
Staff Reviewer for Game Tunnel, the Independent Underground:
http://www.gametunnel.com

3

Of course I would find out why AFTER I spend a week trying to figure it
out and then emailing the list.

The changelog for libSDL:

SDL 1.2.11 Release Notes

SDL 1.2.11 is a minor bug fix release.
Unix Notes

Anyway if your target is to build for the wider range of machines you can I
suggest you two roads:

  1. Build with a old distro
  2. Build with autopackage gcc extension (apgcc), look at autopackage.org for
    details.

The second option is better, I’ve used it in my last commercial game port
and got about 0 installation problems, while the previous attempt that used
1 got a lot of installation related problems.

apgcc is a script that removes dipendencies from newer version of glibc,
disabling stack check and forcing the use of OLD symbols for locale and
other glibc apis evolved in 2.2 and 2.3. It also optionally statically link
some x11 libs, strips unneeded dependencies in link stage, and sets rpath
for library loading in the correct way for loading libraries from a local
path without having to mess with LD_LIBRARY_PATH.–
Bye,
Gabry

4

Gabriele Greco wrote:

Anyway if your target is to build for the wider range of machines you
can I suggest you two roads:

  1. Build with a old distro
  2. Build with autopackage gcc extension (apgcc), look at autopackage.org
    http://autopackage.org for details.

The second option is better, I’ve used it in my last commercial game
port and got about 0 installation problems, while the previous attempt
that used 1 got a lot of installation related problems.

apgcc is a script that removes dipendencies from newer version of glibc,
disabling stack check and forcing the use of OLD symbols for locale and
other glibc apis evolved in 2.2 and 2.3. It also optionally statically
link some x11 libs, strips unneeded dependencies in link stage, and sets
rpath for library loading in the correct way for loading libraries from
a local path without having to mess with LD_LIBRARY_PATH.

I tried using apgcc, but one of my libraries, the Kyra Sprite Engine,
has lost its maintainer, and since I had already been using it, I
starting messing with autotools to get it to actually work in the first
place and then had to fix a few issues as I continued. Now that I am
trying to actually distribute my game, I tried using apgcc to build my
libraris, including Kyra, and Kyra won’t build, possibly because it is
hardcoding the use of gcc somewhere. I thought that if I could get away
without messing with Kyra again, it would be better just because I plan
on getting rid of Kyra after this project.

When you say that the first option gave you installation related
problems, what kind? I was under the impression that using an older
distro would result in libraries that would remain compatible with
future distros and that apgcc was just making sure you used the old
symbols anyway.

I have since found
http://listas.apesol.org/pipermail/sdl-libsdl.org/2008-January/064001.html
which links to Gerry JJ’s script: http://delirare.com/files/gensymoverride

Either it isn’t currently working, or I must don’t understand how to use
it. First I found out that I needed to run it with bash, not sh. Then I
thought that it wasn’t producing the output correctly since I kept
seeing what looked like library names flickering on a single line in my
xterm while occasionally seeing a few asm lines. Then I figured out
that those lines WERE the contents of the header file, but a lot of them
would say that certain symbols didn’t exist prior to GLIBC_2.4, which
prevented me from using the header in my build.

It seems my only options are to do the work of removing Kyra from my
build, which requires replacing its functionality, or hacking at Kyra to
figure out why apgcc won’t build it. Well, I could do the work of
setting up a chrooted environment so I can use older libraries to build
my game, but I am having trouble finding information on doing so. And I
could use an older distro, but besides having to find a spare machine to
run it on, now you’re saying that it isn’t without its problems.

Thanks,
Gianfranco–
GBGames’ Blog, An Indie Game Developer’s Somewhat Interesting Thoughts:
http://www.gbgames.com/blog
Staff Reviewer for Game Tunnel, the Independent Underground:
http://www.gametunnel.com

5

When you say that the first option gave you installation related
problems, what kind? I was under the impression that using an older
distro would result in libraries that would remain compatible with
future distros and that apgcc was just making sure you used the old
symbols anyway.

The problem is all about library requirements.

If you use complex libraries you will have for instance dependencies from
libpng or libz (two libraries that had big api changes since the old distro
I used, redhat 8.0), you can have direct dependencies and these can be
solved also with static link but if not only the main binary depends from a
system library but also some support library you’ll have to make sure the
right version of the libraries is called, so you’ll start messing with
LD_LIBRARY_PATH and executable/libraries rpaths.

The problem you’ll have if you play too much with them is that you can broke
the way some distro rely on them, for instance SUSE and Fedora use
LD_LIBRARY_PATH to supply both software and hardware accelerated opengl
implementation.

Also X11 libraries of XFree86 are different from XOrg ones, I found a few
problems with freetype and I finished with shipping also that one in the
installer…

You can have also a few problems with audio, modern systems are alsa based,
but if you don’t install a modern version of alsa libraries on your "old"
machine you’ll have symbol size mismatches at runtime…

Anyway if your game or some of your dependencies are in C++ you’ll have to
supply your own libstdc++, since newer distro will not have for sure
libstdc+±5 or libstdc+±3 (the first if you’ll compile with gcc3.2-3.3 the
latter if you compile with gcc3.0 or 2.9x).

The other negative point is that you’ll loose all the optimizations and new
features of modern gcc versions…

Anyway you can archive what apgcc does also without it, look inside the
script /usr/bin/apgcc, it’s well commented, most of the “magic” is done with
compiler command line switches and an header file called apsymbols.h.On 4/16/08, Gianfranco Berardi wrote:

–
Bye,
Gabry