背景：產品需要給使用者提供呼叫的.so檔案。但使用者的伺服器glib庫版本比較低是2.12版本，同時又因為伺服器是生產環境，不能隨便公升級庫檔案。而我們內部的編譯機器由於相容c++新特性的原因，都已經公升級到2.14版本以上了。這樣導致編譯出來的.so檔案不能正常在客戶機器上呼叫。那就想辦法做相容吧。
客戶呼叫報錯如下：
很明顯的就是glib版本問題啦。
解決辦法：
最開始我的想法是想做到類似windows環境上使用靜態環境庫編譯方式，不過可惜沒有查到相關資料。那就換個思路，想辦法把編譯使用時的庫版本指定成低版本。先查自己的.so中的情況，使用objdump發現庫中只有memcpy使用了glib2.14，那就好辦啦。再讓客戶查一查他們機器上的這個函式使用的版本 objdump -t /lib64/libc.so.6 |grep memcpy
用彙編指令.symver可以完成版本指定(確保在所有呼叫 memcpy之前完成彙編指令的版本指定):
asm(".symver memcpy, memcpy@glibc_2.2.5");
編譯完再檢視一下庫情況，一切ok，版本降下來了。庫發給客戶，呼叫一切正常。
參考資料:
ubuntu 環境裡，指定glibc版本執行程式
我把它解壓到lib00資料夾裡 dpkg x libc6 2.31 0ubuntu9.1 amd64.deb lib00 利用pwntools工具，指定ld.so和libc.so.6，來執行程式，指令碼是這樣的 from pwn import context.log level debug sh p...
高版本轉低版本 iOS高版本備份如何匯入低版本思路
又是乙個快樂的上班摸魚的一天，好久都沒更新了，這段時間一直在忙於出差送貨，學長最喜歡的週末也都 碰巧 的雙休變單休了，學長忍不住心疼學長我自己個er。可能有小夥伴覺得，不就是更新一篇文章嘛，抽個空不久更新了嘛，這麼多廢話幹嘛？誠然，更新一篇文章抽個空就可以了，但是相對於質量學長真心不敢苟同，學長寧願...
開發環境與DevExpress的版本相容關係
專案編譯是沒問題的。但除錯執行時，出現 未能載入檔案或程式集 找到的程式清單與程式集引用不匹配 等奇奇怪怪的問題。在確認所引用的dll檔案無誤後，覺得可能是因為專案遷移，開發環境改變導致的版本相容問題。翻看官方手冊，有豁然開朗的感覺。以下是devexprss與.net版本及visual studio...