Not every Linux distro is the same. Hence the reason why every distro has their own package manager and it's own set up packaged versions.

On Linux it's often much easier to just give the source code to the user so he can compile it himself.

"I really don't want to have to set up a whole new installation with an old version of GLIBC just to recompile it again"

That's not how you do this. You do this with what is called a "chroot".

A chroot (pronounced "chuh-root") is a unix environment INSIDE another unix environment. It's not virtualisation or emulation, it's much more lightweight than that. You simply build a file tree containing a build environment -- typically it will be just the basic minimum packages to do the build, and including *specific* versions of libraries to link against. You then copy your source (or partially built system) into it, and perform the final link.

Here's a document which talks about setting up a chroot;

http://wiki.blender.org/index.php/Dev:Doc/Setting_Up_a_Chroot_Build_Environment_under_Linux

It's actually about how to build blender, but it's got the general stuff in it. Basically chroot starts a new shell and will execute commands, but after setting an environment where / is actually somewhere else. The shell (and its children processes) aren't allowed to peek outside their particular part of the file system.

So you set up a new directory somewhere, and it'll have its OWN /etc, /bin and so on. Of course, it's not a full operating system, so you don't actually get an /etc/passwd in there. What you do then is copy packages somewhere in that tree and then have chroot execute a shell script which installs them. It'll install them into its /bin directory. Then you chroot a script which does your build inside it, then you copy out the completed build.

Building the chroot for the first time can be a little expensive, but you can keep it lying around for when you need it. Many software development teams check the completed chroots themselves into their revision management systems, or keep pristine copies of them on fileservers so they can be just cloned onto build servers when needed. Another reason for doing this is that it makes your build independent of your development environment. You don't need to worry about installing games or whatever on your machine, because even if they upgrade (say) your opengl libraries, you KNOW the version in the chroot is the one you actually want to build against. You don't have to stop doing local builds either -- you can still do that which means all the symbols and source are easy to get at and so on.

Also, you can then (reasonably trivially) build cross-distribution software. For example, I routinely build red-hat RPMs for various version of redhat on my Ubuntu desktop. Why? Well the chroots are fresh -- so I can install anything I want in them, it doesn't have to be the distro on my desktop. So I've got a RedHat 5.6 chroot, and a RedHat 6.0 chroot and also a Suse Enterprise chroot and I can build things in there that will run on those different distros.


There are two things you'll encounter. One is you'll need to find a sufficiently low version of glibc in order to install it in the chroot. Good news is you often get away with just nicking the file itself from somewhere and overlaying that onto a package install.

The next thing is what'll probably get you. The reason that your program is demanding those symbols to dynamically link at runtime is that they're part of a feature in glibc that you're using in your app which only appears in later versions of the library. That's why they're there. It's not Linux being crazy, it's a safety precaution to stop you running apps which need features which aren't present in the local version of glibc. In other words, even if you forced this to work, your app is going to crash. Eventually it'll call an ioctl not supported by the kernel or look-up a glibc entrypoint which doesn't exist or something.

This is how, for example, you get new API calls safely added to glibc. They have an internal versioning system which says "this'll only work on THIS version or higher". Windows, by the way, does exactly the same thing only instead of complaining about missing symbols like that it pops up a message box saying something like "This program cannot be run because there are parts of its environment missing" but crucially doesn't tell you which version of the c runtime will be sufficient to run it...

You *can* solve this by finding out what's dragging those symbols in and programming around that. The STL is particularly fond of this, but other things will do it as well. If you can locate them and it's something you have an alternative for then you can simply use the alternative. I've fixed compilation errors in this way before -- ISTR one was something like an STL linked list operation needed the feature but the equivalent for vectors didn't so I rewrote the one container which was causing the problem to used a vector, took the performance hit for vector resizing (which was small enough not to worry) and now my app "just worked" on the target systems.

Centos, RHEL, SLES and some other distros intended for 'enterprise' type machines have relatively old (aka 'stable') versions of most software compared to something like Ubuntu so you have to be aware of that if you intend to distribute binaries.