Linux Game Development: GLIBC_2.4 Errors Solved

Last week, I wrote about the `GLIBC_2.4′ not found errors your game might get when an application built on a new distribution is run on an older distribution, such as Debian Stable and Slackware 11.

Judging from my search logs, this problem seems to be common enough to warrant a follow-up post. I have since solved the problem and haven’t added new dependencies, and it doesn’t involve using strange, mysterious scripts or older compilers.

In my last article, I referred to a compiler flag that was supposed to use a specific C++ ABI. I found some success with it, but it would add X11 dependencies to my libraries. Ideally you would like to remove these dependencies along with the dependency on GLIBC_2.4.

The Solution

While researching this issue, I found multiple websites referring to an entirely different compiler flag. This flag disables a feature that is specific to GLIBC_2.4 and higher, and so programs would no longer depend on 2.4 if the flag was used.

I spent way too much time trying to figure out what I was doing wrong when I discovered that each of these websites spelled the compiler flag wrong!

It is NOT -fnostack-protector! It is -fno-stack-protector!

In my custom library build scripts, I have:


export CC=gcc
export CXX=g++
export CFLAGS="-fno-stack-protector"
export CXXFLAGS="-fno-stack-protector"


In my game build script, I just add -fno-stack-protector to the beginning of my CFLAGS variable in the Makefile.

The Results

When my custom libraries are built using these flags, they no longer depended on GLIBC_2.4.

Unfortunately, I saw that libSDL did have a new dependency on libvga. I fixed that issue quickly enough! When I passed parameters to the configure script for libSDL, I added “–disable-video-svga”, and the dependency no longer exists.

If you’re curious, my full configure parameters for libSDL are:


--prefix=$LIB_DIR --enable-X11-shared --disable-rpath --disable-ipod --disable-video-directfb --enable-sdl-dlopen --disable-video-svga


where LIB_DIR points to wherever my project is installing the custom libs. If you’re curious about why I have custom libraries or how I chose these parameters, I can’t recommend Troy Hepfner’s Linux Game Development series enough.

GLIBC_2.4 No More!

By using the compiler flag -fno-stack-protector for my custom libraries and my game, I remove the dependency on GLIBC_2.4, allowing my game to run on newer systems and older systems alike. So far my beta testers inform me that my game continues to run fine on newer systems, and the people with older systems are now able to play my game, too.

If you’re concerned about what -fno-stack-protector does, it removes checks that help protect against stack-smashing attacks. Ideally if everyone was using up-to-date systems with stack protection on, you wouldn’t need to worry about trying to make your game run on older systems. If you are concerned about security, you could provide two binaries, one for the older systems and one for the newer systems, and have a script dynamically determine which to use.

For more information on this issue:

• My Linux Game Tome forum post on this subject
• Troy Hepfner’s excellent Linux Game Development series
• GCC extension for protecting applications from stack-smashing attacks
• My frustrations with this solution not working quite right on Ubuntu

[tags] linux, game development, business, programming [/tags]