The shared library system for linux, especially when it comes to libc, is (choose one): archaic|complex|awesome. Today in trying to run some software on our local cluster, I encountered this lovely error:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
Why was this occurring? For some reason, there was a version bump in the glibc for the memcpy instruction. How memcpy’s interface could possibly changed in a non-backward-compatible fashion, I don’t know. Still, since my local machine has a later libc then our cluster machines, I’m effectively boned.
There is a way around this, namely, I can ask the compiler to emit references to a specific, older version:
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
Unfortunately, this code has to appear before any other uses of memcpy! Rather then update a whole lot of code, I took advantage of the -include option for gcc. I simply created a file with my desired symbol override:
# gcc-preinclude.h
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
and forced the build (here, autotools) to always include that before any other code:
./configure CC=gcc -include /path/to/gcc-preinclude.h ...
And away we go. A full rebuild and I’m back to a usable program again. Hurray!
Isn’t this due to “backwards memory copying” changes in memcpy: http://lwn.net/Articles/414467/ , http://sources.redhat.com/bugzilla/show_bug.cgi?id=12518 ?
(it sounds like your software was built against a new glibc but being run on a system with an old glibc – perhaps it would be safer to do builds on the older system?)
(additionally “run some software on our local software” doesn’t quite scan)
You’re right – that’s exactly the situation – my desktop machine is running a newer distribution then our cluster machines. Normally, I do end up compiling on the older machines when this type of thing crops up, but I was curious if I could avoid doing that in the future.
Sorry about the typo – that’s what happens when I type in a hurry