我的问题源于一个共享库，我没有选择重新编译该库。错误指出undefined reference to 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
to:
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？
如果有人能给我一些关于这个主题的见解或提供一些相关信息的链接，我将不胜感激。
我想知道的是这会产生什么影响。
最可能的影响是您的第 3 方库第一次调用memcpy，它会崩溃。
有一个reason的新版本memcpy@GLIBC_2.14被引入：它与旧版本不兼容 ABImemcpy（这里发生的事情是，从 GLIBC-2.14 开始，memcpy is a GNU_IFUNC，这意味着它返回实际的地址memcpy;然后，第 3 方库中的代码将call返回的例程。但返回值是memcpy@GLIBC_2.2.5是目标参数而不是函数地址，因此预计您会立即崩溃）。
如果有人能给我一些见解
给你的图书馆requiresGLIBC-2.14。通过在 GLIBC-2.12 机器上运行它，您已经使所有保修失效。您最好的选择是：
- 与第三方供应商合作以获得与您的执行环境兼容的库版本，或者
- 使您的执行环境与您提供的库兼容（即更新您的操作系统）。你也许应该这样做anyway因此您的系统不会受到最近的漏洞的影响，例如CVE-2015-7547.
Update:
我没有使用 memcpy 的返回值
你没明白怎么办GNU_IFUNC的工作。这里有一个描述。问题是，虽然you不使用返回值，动态链接器does.
动态链接器内的代码执行以下操作：
if (symbol type == STT_GNU_IFUNC) {
// call the IFUNC to get an address of the actual implementation
void (*pfun)() = memcpy();
// call the actual (non-IFUNC) implementation of memcpy.
return (*pfun)(to, from, size); // You will crash here!
}
通过替换非ifunc版本为infunc-通过 asm hack 的版本，你保证pfun == to，所以你的to被调用就像它是一个函数一样。通常应该立即SIGSEGV.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
