由於工作平台環境限制的緣故(見buildroot: 三個願望一次滿足一文),
所以當時採用了buildroot, 以利於產生toolchain與使用uClibc
當然, 單單在個人環境下使用buildroot不太會有問題
(意外是會接二連三發生的...:P)
最近要與他人co-work, 所以要把開發環境設好
天真如我, 反射性地, 就把 buildroot目錄下的 build_arm/staging_dir 打包後丟了出去
直到同事遇到了一堆 include/library search path 問題, 向我反映, 這才發現不妙
套句國見比呂的話, 現在才想要轉用crosstool-ng實在是太遜了
而使用alias 去傳入 sysroot 參數對於別人也不是好主意
問題發生的主要原因在於toolchain 對於 include/library search path找不到所需檔案
簡單的說, 就去觀察toolchain的path 設置, 並且把找不到的檔案放在適當位置即可
預設的include path可以透過 arm-linux-cpp -v 來取得
而library path 是由 arm-linux-gcc -print-search-dirs 取得
接著就是做一些file link or move
比較要注意的是libc.so 這個文字檔, 把裡面GROUP的path prefix 移除就可以了
anyway, 不這麼做的話, 比呂和英雄是不會對決的...
但是我們可不會水平外曲球, 下次還是改用crosstool-ng or scratchbox吧
訂閱:
張貼留言 (Atom)
在 ARM 平台上使用 Function Multi-Versioning (FMV) - 以使用 Android NDK 為例
Function Multi-Versioning (FMV) 過往的 CPU 發展歷程中, x86 平台由於因應各種應用需求的提出, 而陸陸續續加入了不同的指令集, 此外也可能因為針對市場做等級區隔, 支援的數量與種類也不等. 在 Linux 平台上這些 CPU 資訊可以透過...

-
現今對於 Daily Linux Developer / User 面對不同程式/開發版本環境感到很頭疼, 常常疲於 執行舊版程式需要安裝舊版本 Library, 設定 RPATH / LD_LIBRARY_PATH 開發需求建立不同的版本 SDK 開發/執行環境, 在較舊系統...
-
這幾年個人在影像處理程式優化的領域打滾, 如果問到感到棘手的工作, floating point 的處理應該可以排上很前面的名次 在許多演算來說由於同時對於 precision 與 dynamic range 的需求, 因此在計算過程中對於浮點數的使用是非常常見的 (若要避免...
-
曾提過 許多的 OpenCL 的 wrapper 都不重視 Image 這個型別, 僅僅提供 Buffer 的物件, 這樣的作法除了錯誤地認為都僅只是 memory buffer 外, 忽略了 GPU 架構設計上的本質是相當可惜的. 在 CPU 上 memory ac...
沒有留言:
張貼留言