Since the source code for this wkhtmltoimage tool is available, I'd
suggest you
recompile it
from source with your system's native glibc. It will likely be even
quicker than recompiling glibc, which is no easy task.
A statically linked executable already includes code for all the C
library calls it needs to make, so you cannot separately compile a new
glibc and link the executable to it. However, programs using glibc
are never completely static: some library calls (all those connected
with the "Name Service", i.e., getuid() and similar) still make use
of dynamically-loaded modules (the libnss*.so files usually found
under /lib). This is likely why the program is failing: it is
looking for some NSS module but can only find the glibc2.3 ones.
If you absolutely want to go down the road of recompiling glibc, the
following could possibly work (Warning: untested!):
configure glibc2.4 to install in a non-system directory,
e.g. /usr/local/glibc2.4, then compile and install;
run wkhtmlto* by specifying it as the first component in the
dynamic linker search path (LD_LIBRARY_PATH):
env LD_LIBRARY_PATH=/usr/local/glibc2.4/lib wkhtmltoimage ...
Update: This turned out not be so easy: having two distinct libc's on the system
requires more than just recompile/install, because the libc will look for the runtime linker and dynamic-load NSS modules in fixed locations. The rtldi program allows installing different versions of the GNU libc on a single Linux system; its web page has instructions (but this is an expert-level task, so they are definitely not a step-by-step walkthrough).
Let me stress again that it will be far less work to recompile wkhtmltoimage...
Yes, it's possible. You'll have to be very careful with the library load paths, and you may need to recompile some other libraries.
As the path of least friction, I recommend installing an older version of Debian or Ubuntu in a chroot. That is, make a directory, say /old/etch, and install the older distribution in the tree rooted there; to run that problematic program, call chroot to restrict its view of the filesystem to /old/etch.
Debian (or Ubuntu) comes with a package to assist with installing another system in a chroot: schroot (successor of dchroot). First, use debootstrap to install the older distribution (install only the base system and what your program needs, no servers). Then set up schroot to run the program conveniently (with /dev, /proc, /home and other “satellite” filesystems accessible).
So the plan is: debootstrap, then dchroot. In How do I run 32-bit programs on a 64-bit Debian/Ubuntu?, I give a tutorial about a similar setup − whether you're running different versions of the distribution, or different architectures, or different Debian-like distributions, it's only a matter of selecting the appropriate package source, the rest is the same.
Best Answer
If it were for any other library, but glibc ... I suppose there can't be quick ways, because the glibc is the place where stuff is "hard coded". The glibc fits to your kernel version and its loader is the instance that actually does the right thing (TM) with
LD_LIBRARY_PATH.Maybe the correct way is to:
Not sure if this works, though.
At any rate, I think using an alternative glibc requires a yet to implement framework, because search paths are wired sometimes and the glibc always has to fit your OS/kernel, so there can't be generic binaries, IMO. Debian's multiarch shows that it's not trivial, but still can be done. If one was to have some other means of discerning libraries besides the target architecture.
The website just gave me this other related thread:
There, the accepted answer includes a link to a program called rtldi, which seems to solve the glibc issue. It's from 2004 so it may not work right out of the linker anymore, but maybe its worth looking into. Its source is GPLv2.
Jehova, Jehova
A friend of mine once came up with the idea, that the actual use of shared libraries is overrated. And he does have a point: shared libraries are good to not fill up your computer's memory with duplicates, but considering the individual application instance this is only a few MBs.
There is only a few applications where we would resort to actions such as providing them their own glibc. Saving us a lengthy analysis let's call them "immediate applications", that are of use by themselves, in the sense of getting work done. For example web browsers, mail user agents, office suits and music players allow the user to get what they want and there are only a few instances per user. To portrait the other side, system services, window managers, even entire desktop environments are all very important, but merely supporting and often not sufficiently uncommon or critical, so that people would be willing to give them their very own glibc.
The number of "immediate applications" is rather small, absolutely per user and relatively compared to what "basic" OSs and DEs spawn these days. If immediate applications, like Chrome, Firefox were compiled statically, the additional memory requirement for the average system would be a few 100MB. An argument that doesn't carry very far on today's many GB systems so statical linking for immediate applications can be an option.
There are also the concepts of swap space and SSDs which allow for rediculously fast swapin/-out, which also helps handling the increaed memory requirement.
The glibc issue discussed here is not really resolved though static linking, but for applications like web browser a sort of self contained distribution format is conceivable, where the X protocol, some sound daemon and some kernel meethods as the only interface. The advantage would be fewer library version incompatibilities.