這週花了大部分的時間在處理這件事上
繼先前share buildroot toolchain with others之後
接著近日又被詢問了 c++ compiler 的環境
當下看了看buildroot configuration 中 Toolchain 項目有著一行
[] Build/install c++ compiler and libstdc++?
心想著這應該不過 30 分鍾就可以搞定了
接著就是一連串疑問的開始
編譯過程中, 編譯 libsupc++ 時錯誤發生了
/tmp/ccxY0pxQ.s: Assembler messages:
/tmp/ccxY0pxQ.s:423: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:580: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:581: Error: duplicate .handlerdata directive
/tmp/ccxY0pxQ.s:948: Error: duplicate .personality directive
/tmp/ccxY0pxQ.s:949: Error: duplicate .handlerdata directive
make[5]: *** [eh_alloc.lo] Error 1
而即便以相似設定以 crosstool-ng 編譯也會在相同點出問題
以buildroot和錯誤訊息作為關鍵字搜索, 可以看到一些資訊, 然而無有效線索
只好嘗試往 source code 找尋蛛絲馬跡
最後找到的是處理 exceptions 相關的部份
於是檢視一下buildroot有關exception的設定, 同在 Toolchain 內有著另外一行
[*] Enable setjmp/longjmp exceptions?
該項目主要是在編譯 gcc 時增加了一個設定項目
--enable-sjlj-exceptions
簡單地說, 是以呼叫 setjmp/longjmp 的方式來作exception handling
而事實上 libsupc++ 亦是C++中處理exception的部份
雖然沒有繼續trace, 然而應該是該部份與 C library 的部份有衝突
所以這問題應該與 uClibc 是有相關的
另外, 如果不使用 setjmp/longjmp 的 exception handling model
則採用的是 call frame unwinding 的方式
這兩者間的差異和優缺就不多說了
訂閱:
張貼留言 (Atom)
在 ARM 平台上使用 Function Multi-Versioning (FMV) - 以使用 Android NDK 為例
Function Multi-Versioning (FMV) 過往的 CPU 發展歷程中, x86 平台由於因應各種應用需求的提出, 而陸陸續續加入了不同的指令集, 此外也可能因為針對市場做等級區隔, 支援的數量與種類也不等. 在 Linux 平台上這些 CPU 資訊可以透過...
-
在 Halide 的使用上會有錯覺地認為 Halide::Runtime::Buffer 的使用必須與 libHalide.so or libHalide.a linking 才可以. 但其實 Halide::Runtime::Buffer 是可以單獨使用的, 只需要 head...
-
現今對於 Daily Linux Developer / User 面對不同程式/開發版本環境感到很頭疼, 常常疲於 執行舊版程式需要安裝舊版本 Library, 設定 RPATH / LD_LIBRARY_PATH 開發需求建立不同的版本 SDK 開發/執行環境, 在較舊系統...
-
在講解 680 中的 SIMD 單元 - HVX 之前, 還是先以 系列文 I 的 blocks diagram開頭, 並且今日重點會是文中提到第3點的官方文件 從 blocks diagram 中可以看到 HVX 由三個主要部分所組成 VX : Vector ...
2 則留言:
請問當我要更改一個uclibc-config的設定, 是否需要make distclean, 再重make呢?
還是可以make clean就好?
Thanks..
無需 distclean, make clean 即可
distclean會將設定刪除
張貼留言