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

回答

相關問題