交叉編譯時遇到的乙個坑

2021-10-19 15:20:47 字數 1186 閱讀 2830

由於我們的板子是arm架構,而開發使用的pc機器是x86架構,所以在pc機上開發出來的程式要想在arm板子上執行,需要用交叉編譯工具鏈,類似arm-linux-gcc這種,編譯成arm平台上可執行的二進位制檔案才可以。如果你除了自己寫的**,還引用了一些第三方庫,類似boost這種,你還得把boost庫也用交叉編譯工具重新編譯下才能用。當然還要注意32位64位這種問題。

我一開始只把g++換成了arm-linux-g++,編譯後執行,結果報錯說找不到動態庫。所以我決定進行靜態編譯,將需要的庫都編譯進可執行檔案中,在目標平台上可直接執行。

於是我就在makefile檔案的後面加了乙個-static,來進行靜態編譯。編譯成功了,但是有乙個tcp的某個函式裡有乙個關於glibc的警告,如下:

但我沒管他,想著如果tcp出現問題再去看這個警告。

於是我再執行的時候果然就可以成功執行了。正當我開心的時候,問題出現了:

板子上執行的程式好好的,在用boost庫解析xml的時候突然發生了段錯誤。我順著發生段錯誤的地方,一行一行除錯,最終鎖定了在了乙個boost庫new出來的區域性變數上。

現象是,只要這個變數被釋放,程式就會段錯誤。

這真是奇了怪了。大家知道區域性變數都是存在棧區的,而且離開作用域即會釋放記憶體。乙個區域性變數招誰惹誰了,居然一釋放就段錯誤?

我懷疑是系統的問題,平台的問題,板卡的問題。於是我更換了另乙個arm平台的板卡,發現一模一樣的段錯誤也發生了。其他的關於程式上的懷疑也不對,因為該程式在x86平台上執行的好好的,所以程式出bug的可能性也很小。

十分不合常理的問題。雖然出錯的是boost 的區域性變數,但是這種詭異或不合常理的事情一發生,那你就不能從眼前那個問題去找答案了,它可能是別的問題,引發了眼前的這個極其不合常理的問題。至此,我開始回頭看那個警告。

arm-linux-g++ main.cpp -o server -wl,-dn -l/boost/lib -lboost_serialization  -wl,-dy -lpthread
編譯後果然沒有警告了。

我放到板子上執行以後,發現報錯找不到c++標準庫,即libstdc++.so.6.這個板子上啥都沒有,c++的標準庫還是裝乙個比較好,要不然連helloworld都執行不了。所以我拷貝了乙個32位的libstdc++.so.6的動態庫到板子上,再執行就全部ok啦。

關於TSnackbar遇到的乙個坑

這幾天研究了一下頂部snackbar,發現網上有個神器,tsnackbar 感謝作者!但是遇到了乙個問題 這可急壞了我,研究了一下原始碼,然後跟蹤了一下,定位到自定義控制項的內部,但是看了半天也沒發現什麼問題,後來想著這種inflate錯誤一大半原因都是布局導致的,所以我開啟了布局檔案,逐個對照,漸...

2020 12 05 今天遇到的乙個坑

public class aistatemove aistate space 10 go to this state if passive event occures public aistate passiveaistate end point for moving hideininspector...

return 時遇到的乙個問題

今天做業務時遇到了乙個問題 我公司 上游公司 需要接收到 下游公司返回 return 的乙個字串 string string notify 我公司 上游公司 接收到的字串 業務 當我公司 上游公司 接收到下游返回的是 keyi 時,system.out.println 成功 否則,system.ou...