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
...
/lib/libnss*.so
, and finding the glibc2.3 ones. I know of no solution to this... – Riccardo Murri Oct 05 '10 at 07:27