解决 version `GLIBC_2.14‘ not found 错误

秒速五厘米 2022-12-06 01:15 362阅读 0赞

在glibc版本小于2.14的系统上，运行高版本gcc编译的程序是会出现以下错误：

version \`GLIBC\_2.14' not found

解决方案有以下几种：

1. 静态编译  
   -static-libgcc -static-libstdc++ -nodefaultlibs -shared -fPIC

2. 在源文件中添加以下代码，并重新编译

\_\_asm\_\_(".symver memcpy,memcpy@GLIBC\_2.2.5");

3. 使用glibc版本小于2.14的系统的gcc进行编译

这个问题的本质原因请参考：[https://www.win.tue.nl/~aeb/linux/misc/gcc-semibug.html][https_www.win.tue.nl_aeb_linux_misc_gcc-semibug.html]

# A gcc regression #

Recently I stumbled over a gcc problem, I am tempted to call it a bug. Infrequently I compile programs and upload them to a web server to which I only have ftp access. This always worked, but not any longer. Why not? Unfortunately the server reacts to any problem by showing its home page - like with the old "?" in ed, one knows that something is wrong, and may figure out the rest. Small programs worked, big programs failed, and after a while I had a minimal failing program.

#include <string.h>
    
    char *qq, *aa;
    
    int main(int argc, char **argv) {
            char *q = qq;
            int n;
    
            n = strlen(aa);
            strcpy(q, aa);
            q += n;
            *q = 0;
            return 0;
    }

(Irrelevant parts removed.) What is wrong? Why does the web server react with the "page not found" reaction of showing its home page? The binary was executable, permissions OK.

% readelf -a test
    ...
    Version needs section '.gnu.version_r' contains 1 entries:
     Addr: 0x0000000000400390  Offset: 0x000390  Link: 6 (.dynstr)
      000000: Version: 1  File: libc.so.6  Cnt: 2
      0x0010:   Name: GLIBC_2.14  Flags: none  Version: 3
      0x0020:   Name: GLIBC_2.2.5  Flags: none  Version: 2
    ...

Hmm. Why does it need GLIBC\_2.14? That is a rather recent library. And indeed, this turns out to be the culprit. The dynamic loader fails, and programs that refer to GLIBC\_2.14 are non-executable on this web server.

## memcpy@GLIBC\_2.14 ##

Why is such a recent library needed for such a simple program?

% readelf -a test | grep 2.14
         4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@GLIBC_2.14 (3)
        59: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@@GLIBC_2.14
      004:   3 (GLIBC_2.14) 
      0x0010:   Name: GLIBC_2.14  Flags: none  Version: 3

Interesting. So my program does not call the function memcpy, but it does call strlen and strcpy and the compiler decides that it would be better to use memcpy, and forces a memcpy from a recent glibc. That means that the compiler output cannot be used on older machines. Bad. Smells like a gcc bug.

## The memcpy *vs.* memmove saga ##

Now that I know what is wrong I can easily find posts from hundreds (maybe even thousands) of people who had the same problem. People advise workarounds like

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

and that works. One can also compile on an older machine, or compile a private version of the toolchain. But such nonsense should not be necessary for very simple programs that have worked for dozens of years. There is a blog discussion [fun with shared libraries — version GLIBC\_2.14 not found][fun with shared libraries _ version GLIBC_2.14 not found], and an old [article][] in lwn.

The original discussion was about the difference between memcpy and memmove, and that in some implementations the former can only be used on non-overlapping areas. This leads to bugs such a [this one][] in mksquashfs, and [this one][this one 1] (with [comments][] from Linus) in the 64bit flash plugin.

That old working programs were suddenly broken was because of the [patch][] by HJLu that was supposed to gain a few ns by copying backwards, but ended up costing thousands of developer hours. Linus tried to measure whether there was a speedup and did not find any.

Andreas Schwab (reacting as if flashplayer were the only program broken by this glibc change) comments: "Tell adobe" and "The only stupidity is crap software violating well known rules that have existed forever". Linus disagrees, gave an LD\_PRELOAD [workaround][], and says "I'd personally suggest that glibc just alias memcpy() to memmove()."

So that was the old saga. HJLu changed glibc. Technically it was doubtful whether the change was a good idea. Maybe there was no speedup. Many old programs broke, a lot of Linux developer time was spent in figuring out why, and there was a lot of discussion. Of course technically such a change is OK, at least if there actually is a speedup and only undefined behavior is broken. See also [this discussion][]. The result was that memcpy@GLIBC\_2.2.5 was aliased to memmove (so old binaries remain happy), and memcpy resolves to memcpy@@GLIBC\_2.14.

## gcc ##

And so it happened that the memcpy's that gcc generates (for struct copies and the like) became memcpy@@GLIBC\_2.14. Unfortunate. Also this broke many projects. Not because of an incorrect call to some function, but because of an added dependency, where the development machine was recent, but the places where the compiled code is going to be deployed have an older glibc. Hundreds of software projects today contain the mysterious line

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

as a lasting memory of this glibc debacle. I just added it to my code as well.

[https_www.win.tue.nl_aeb_linux_misc_gcc-semibug.html]: https://www.win.tue.nl/~aeb/linux/misc/gcc-semibug.html
[fun with shared libraries _ version GLIBC_2.14 not found]: http://rjpower.org/wordpress/fun-with-shared-libraries-version-glibc_2-14-not-found/
[article]: http://lwn.net/Articles/414467/
[this one]: https://bugzilla.redhat.com/show_bug.cgi?id=619020
[this one 1]: https://bugzilla.redhat.com/show_bug.cgi?id=638477
[comments]: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129
[patch]: http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278
[workaround]: https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38
[this discussion]: https://sourceware.org/bugzilla/show_bug.cgi?id=12518