memcpy memmove的解释GLIBC_2.14/2.2.5

我的问题源于共享库我没有选择重新编译库。错误规定为undefined reference to [email protected]_2.14。memcpy memmove的解释GLIBC_2.14/2.2.5

我机器上的GLIBC版本是2.12。我见过修复人们使用线路

__asm__(".symver memcpy,[email protected]_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版本？

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

来源

2016-02-26 PickleWeasel

我想知道的是这会有什么效果。

最可能的影响是，您的第三方库第一次调用memcpy时，它会崩溃。

有一个原因引入的[email protected]_2.14一个新版本：它与ABI不兼容旧memcpy（这里发生的事情是，作为GLIBC-2.14，memcpy是GNU_IFUNC，这意味着它返回的地址的实际memcpy;第三方库中的代码然后将调用返回的例程，但返回值[email protected]_2.2.5是目标参数而不是函数地址，因此您应该立即崩溃）。

如果有人可以给我一些见解

给您提供此库需要 GLIBC-2.14。通过在GLIBC-2.12机器上运行它，您已经无视所有保修条款。最好的办法是要么：

与第三方供应商合作来获得一个版本与执行环境兼容的库，或
让您的执行环境，您将得到磁带库兼容（即更新OS）。你应该可以这么做因此你的系统不能被最近的漏洞所影响，比如CVE-2015-7547。

来源

2016-02-28 03:43:21

_TO得到与执行相兼容的库的版本environment_ 有什么办法交叉编译库或可执行文件，因此它需要比GCC工具链使用的一个较老版本的glibc？ – scrutari

@starfury是的，有，但它不是微不足道的：http://stackoverflow.com/a/8658468/50617 –

memcpy memmove的解释GLIBC_2.14/2.2.5

回答

相关问题