我的问题源于我给出的共享库,没有重新编译库的选项.错误声明未定义对memcpy@GLIBC_2.14的引用.

我机器上的GLIBC版本是2.12.我见过人们使用该线路在线完成的修复工作

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

我做的修复是使用十六进制编辑器将2.14的引用更改为GLIBC_2.2.5.执行命令readelf -V lib_name.so时,输出更改为：

0x0060  Name: GLIBC_2.14 Flags: none Version 6
......
0x0080  Name: GLIBC_2.2.5 Flags: none Version 4

至：

0x0060  Name: GLIBC_2.2.5 Flags: none Version 6
......
0x0080  Name: GLIBC_2.2.5 Flags: none Version 4

这解决了我的错误.我想知道的是它会产生什么样的影响.我试图研究memcpy与memmove以及从GLIBC_2.14开始对memcpy的更改,但我不太明白发生了什么以及memcpy的原始问题是什么.我担心这个“修复”,虽然它允许我的程序运行,以防memcpy正在做的事情表现不正常.为什么我在网上看到的所有修复程序都专门链接到2.2.5版本？

如果有人能给我一些关于这个主题的见解或提供一些相关信息的链接,我将不胜感激.

解决方法:

What I want to know is what effects this will have.

最可能的影响是,当您的第三方库第一次调用memcpy时,它将崩溃.

有一个原因引入了新版本的memcpy@GLIBC_2.14：它与旧的memcpy不兼容(这里发生的是从GLIBC-2.14开始,memcpy是一个GNU_IFUNC,这意味着它返回实际的地址) memcpy;然后第三方库中的代码将调用返回的例程.但memcpy@GLIBC_2.2.5的返回值是目标参数而不是函数地址,因此您应该立即崩溃).

if anyone could give me some insight

您获得的图书馆需要GLIBC-2.14.通过在GLIBC-2.12机器上运行它,您已经取消了所有保修.你最好的选择是：

>与第三方供应商合作,以获得与您的执行环境兼容的库版本,或
>使您的执行环境与您给出的库兼容(即更新您的操作系统).你应该这样做,所以你的系统不能被最近的漏洞所破坏,例如CVE-2015-7547.