交叉編譯提示後綴格式
1. 使用hane NFS和Ubuntu交叉編譯，成功了，但是在編譯安裝源碼時出現： 遺漏分隔符 。 停止等錯誤。
Windows下的日誌文件格式是NTFS，而linux下日誌文件格式大多是ext4，通過掛載NTFS格式在ext4下，然後在NTFS下編譯文件，一般並不推薦這樣做。
本來兩者處理文件的方式方法就不盡相同，平時通過ntfs-3g 掛載下文件還可以，具體編譯軟體的話中間會涉及到比較多次的NTFS和ext4文件的轉化問題。所以不建議掛載在NTFS格式下編譯軟體。
一般編譯的話有個比較好的習慣是源碼包到/tmp或者直接cd 到 /tmp下wget源碼包編譯。tmpfs（也就是/tmp）的一個主要的好處是它閃電般的速度。tmpfs 文件系統會完全駐留在內存中，讀寫幾乎可以是瞬間的。(重啟後文件消失,所以只能放臨時文件)
2. Linux嵌入式交叉編譯工具鏈問題 淺談
簡介
交叉編譯工具鏈是一個由編譯器、連接器和解釋器組成的綜合開發環境，交叉編譯工具鏈主要由binutils、gcc和glibc 3個部分組成。有時出於減小libc庫大小的考慮，也可以用別的c庫來代替glibc，例如uClibc、dietlibc和newlib。交叉編譯工具鏈主要包括針對目標系統的編譯器gcc、目標系統的二進制工具binutils、目標系統的標准c庫glibc和目標系統的Linux內核頭文件。第一個步驟就是確定目標平台。每個目標平台都有一個明確的格式，這些信息用於在構建過程中識別要使用的不同工具的正確版本。因此，當在一個特定目標機下運行GCC時，GCC便在目錄路徑中查找包含該目標規范的應用程序路徑。GNU的目標規范格式為CPU-PLATFORM-OS。例如，建立基於ARM平台的交叉工具鏈，目標平台名為arm-linux-gnu。
交叉編譯工具鏈的製作方法
分步編譯和安裝交叉編譯工具鏈所需要的庫和源代碼，最終生成交叉編譯工具鏈。
通過Crosstool腳本工具來實現一次編譯生成交叉編譯工具鏈。
直接通過網上（ftp.arm.kernel.org.uk）下載已經製作好的交叉編譯工具鏈。
方法1相對比較困難，適合想深入學習構建交叉工具鏈的讀者。如果只是想使用交叉工具鏈，建議使用方法2或方法3構建交叉工具鏈。方法3的優點不用多說，當然是簡單省事，但與此同時該方法有一定的弊端就是局限性太大，因為畢竟是別人構建好的，也就是固定的沒有靈活性，所以構建所用的庫以及編譯器的版本也許並不適合你要編譯的程序，同時也許會在使用時出現許多莫名的錯誤，建議你慎用此方法。
方法1：分步構建交叉編譯工具鏈
下載所需的源代碼包
建立工作目錄
建立環境變數
編譯、安裝Binutils
獲取內核頭文件
編譯gcc的輔助編譯器
編譯生成glibc庫
編譯生成完整的gcc
由於在問答中的篇幅，我不能細述具體的步驟，興趣的同學請自行閱讀開源共創協議的《Linux from scratch》，網址是：linuxfromscratch dot org
。
方法2:用Crosstool工具構建交叉工具鏈（推薦）
Crosstool是一組腳本工具集，可構建和測試不同版本的gcc和glibc，用於那些支持glibc的體系結構。它也是一個開源項目，下載地址是kegel dot com/crosstool。用Crosstool構建交叉工具鏈要比上述的分步編譯容易得多，並且也方便許多，對於僅僅為了工作需要構建交叉編譯工具鏈的你，建議使用此方法。
運行which makeinfo，如果不能找見該命令，在解壓texinfo-4.11.tar.bz2，進入texinfo-4.11目錄，執行./configure&&make&&make install完成makeinfo工具的安裝
准備文件：
下載所需資源文件linux-2.4.20.tar.gz、binutils-2.19.tar.bz2、gcc-3.3.6.tar.gz、glibc- 2.3.2.tar.gz、glibc-linuxthreads-2.3.2.tar.gz和gdb-6.5.tar.bz2。然後將這些工具包文件放在新建的$HOME/downloads目錄下，最後在$HOME/目錄下解壓crosstool-0.43.tar.gz，命
令如下：
#cd$HOME/
#tar–xvzfcrosstool-0.43.tar.gz
建立腳本文件
接著需要建立自己的編譯腳本，起名為arm.sh，為了簡化編寫arm.sh，尋找一個最接近的腳本文件demo-arm.sh作為模板，然後將該腳本的內容復制到arm.sh，修改arm.sh腳本，具體操作如下：
# cd crosstool-0.43
# cp demo-arm.sh arm.sh
# vi arm.sh
修改後的arm.sh腳本內容如下：
#!/bin/sh
set-ex
TARBALLS_DIR=$HOME/downloads#定義工具鏈源碼所存放位置。
RESULT_TOP=$HOME/arm-bin#定義工具鏈的安裝目錄
exportTARBALLS_DIRRESULT_TOP
GCC_LANGUAGES="c,c++"#定義支持C,C++語言
exportGCC_LANGUAGES
#創建/opt/crosstool目錄
mkdir-p$RESULT_TOP
#編譯工具鏈，該過程需要數小時完成。
eval'catarm.datgcc-3.3.6-glibc-2.3.2.dat'shall.sh--notest
echoDone.
建立配置文件
在arm.sh腳本文件中需要注意arm-xscale.dat和gcc-3.3.6-glibc-2.3.2.dat兩個文件，這兩個文件是作為Crosstool的編譯的配置文件。其中arm.dat文件內容如下，主要用於定義配置文件、定義生成編譯工具鏈的名稱以及定義編譯選項等。
KERNELCONFIG='pwd'/arm.config#內核的配置
TARGET=arm-linux#編譯生成的工具鏈名稱
TARGET_CFLAGS="-O"#編譯選項
gcc-3.3.6-glibc-2.3.2.dat文件內容如下，該文件主要定義編譯過程中所需要的庫以及它定義的版本，如果在編譯過程中發現有些庫不存在時，Crosstool會自動在相關網站上下載，該工具在這點上相對比較智能，也非常有用。
BINUTILS_DIR=binutils-2.19
GCC_DIR=gcc-3.3.6
GLIBC_DIR=glibc-2.3.2
LINUX_DIR=linux-2.6.10-8(根據實際情況填寫)
GDB_DIR=gdb-6.5
執行腳本
將Crosstool的腳本文件和配置文件准備好之後，開始執行arm.sh腳本來編譯交叉編譯工具。具體執行命令如下：
#cdcrosstool-0.43
#./arm.sh
經過數小時的漫長編譯之後，會在/opt/crosstool目錄下生成新的交叉編譯工具，其中包括以下內容：
arm-linux-addr2linearm-linux-g++arm-linux-ldarm-linux-size
arm-linux-ararm-linux-gccarm-linux-nmarm-linux-strings
arm-linux-asarm-linux-gcc-3.3.6arm-linux-objarm-linux-strip
arm-linux-c++arm-linux-gccbugarm-linux-objmpfix-embedded-paths
arm-linux-c++filtarm-linux-gcovarm-linux-ranlib
arm-linux-cpparm-linux-gprofarm-linux-readelf
添加環境變數
然後將生成的編譯工具鏈路徑添加到環境變數PATH上去，添加的方法是在系統/etc/ bashrc文件的最後添加下面一行，在bashrc文件中添加環境變數
export PATH=/home/jiabing/gcc-3.3.6-glibc-2.3.2/arm-linux-bin/bin:$PATH
至此，arm-linux下的交叉編譯工具鏈已經完成，現在就可以使用arm-linux-gcc來生成試驗箱上的程序了！
3. ARM交叉編譯時鏈接錯誤，提示collect2: ld returned 1 exit status，求解答
libVimbaC.so編譯的不對, 使用arm gcc鏈接so命令:
arm-none-linux-gnueabi-gcc -o libVimbaC.so -shared ..... VimbaC.cpp
就可以編譯出arm下用的動態庫了.
4. linux下用交叉編譯器編譯時，已經指定了庫的路徑跟庫的名字，可是還是報錯找不到庫。
看起來它不是個庫，倒像是個可執行程序
一般so都放在lib這樣的目錄下，你這個是bin，而且和它在一起的都是可執行程序，並且它沒有so後綴名。
5. linux交叉編譯生成的文件如何下載。
用開發板自帶的燒寫程序
6. 交叉編譯器 arm-linux-gnueabi 和 arm-linux-gnueabihf 的區別
自己之前一直沒搞清楚這兩個交叉編譯器到底有什麼問題,特意google一番,總結如下,希望能幫到道上和我有同樣困惑的兄弟…..
一. 什麼是ABI和EABI
1) ABI: 二進制應用程序介面(Application Binary Interface (ABI) for the ARM Architecture)
在計算機中，應用二進制介面描述了應用程序（或者其他類型）和操作系統之間或其他應用程序的低級介面.
ABI涵蓋了各種細節，如：
數據類型的大小、布局和對齊;
調用約定（控制著函數的參數如何傳送以及如何接受返回值），例如，是所有的參數都通過棧傳遞，還是部分參數通過寄存器傳遞；哪個寄存器用於哪個函數參數；通過棧傳遞的第一個函數參數是最先push到棧上還是最後；
系統調用的編碼和一個應用如何向操作系統進行系統調用；
以及在一個完整的操作系統ABI中，目標文件的二進制格式、程序庫等等。
一個完整的ABI，像Intel二進制兼容標准 (iBCS) ，允許支持它的操作系統上的程序不經修改在其他支持此ABI的操作體統上運行。
ABI不同於應用程序介面（API），API定義了源代碼和庫之間的介面，因此同樣的代碼可以在支持這個API的任何系統中編譯，ABI允許編譯好的目標代碼在使用兼容ABI的系統中無需改動就能運行。
2) EABI: 嵌入式ABI
嵌入式應用二進制介面指定了文件格式、數據類型、寄存器使用、堆積組織優化和在一個嵌入式軟體中的參數的標准約定。
開發者使用自己的匯編語言也可以使用EABI作為與兼容的編譯器生成的匯編語言的介面。
支持EABI的編譯器創建的目標文件可以和使用類似編譯器產生的代碼兼容，這樣允許開發者鏈接一個由不同編譯器產生的庫。
EABI與關於通用計算機的ABI的主要區別是應用程序代碼中允許使用特權指令，不需要動態鏈接（有時是禁止的），和更緊湊的堆棧幀組織用來節省內存。廣泛使用EABI的有Power PC和ARM.
二. gnueabi相關的兩個交叉編譯器: gnueabi和gnueabihf
在debian源里這兩個交叉編譯器的定義如下:
gcc-arm-linux-gnueabi – The GNU C compiler for armel architecture
gcc-arm-linux-gnueabihf – The GNU C compiler for armhf architecture
可見這兩個交叉編譯器適用於armel和armhf兩個不同的架構, armel和armhf這兩種架構在對待浮點運算採取了不同的策略(有fpu的arm才能支持這兩種浮點運算策略)
其實這兩個交叉編譯器只不過是gcc的選項-mfloat-abi的默認值不同. gcc的選項-mfloat-abi有三種值soft,softfp,hard(其中後兩者都要求arm里有fpu浮點運算單元,soft與後兩者是兼容的，但softfp和hard兩種模式互不兼容)：
soft : 不用fpu進行浮點計算，即使有fpu浮點運算單元也不用,而是使用軟體模式。
softfp : armel架構(對應的編譯器為gcc-arm-linux-gnueabi)採用的默認值，用fpu計算，但是傳參數用普通寄存器傳，這樣中斷的時候，只需要保存普通寄存器，中斷負荷小，但是參數需要轉換成浮點的再計算。
hard : armhf架構(對應的編譯器gcc-arm-linux-gnueabihf)採用的默認值，用fpu計算，傳參數也用fpu中的浮點寄存器傳，省去了轉換, 性能最好，但是中斷負荷高。
把以下測試使用的c文件內容保存成mfloat.c：
#include <stdio.h>
int main(void)
{
double a,b,c;
a = 23.543;
b = 323.234;
c = b/a;
printf(「the 13/2 = %f\n」, c);
printf(「hello world !\n」);
return 0;
}
1)使用arm-linux-gnueabihf-gcc編譯，使用「-v」選項以獲取更詳細的信息:
# arm-linux-gnueabihf-gcc -v mfloat.c
COLLECT_GCC_OPTIONS=』-v』 『-march=armv7-a』 『-mfloat-abi=hard』 『-mfpu=vfpv3-d16′ 『-mthumb』
-mfloat-abi=hard，可看出使用hard硬體浮點模式。
2)使用arm-linux-gnueabi-gcc編譯:
# arm-linux-gnueabi-gcc -v mfloat.c
COLLECT_GCC_OPTIONS=』-v』 『-march=armv7-a』 『-mfloat-abi=softfp』 『-mfpu=vfpv3-d16′ 『-mthumb』
-mfloat-abi=softfp，可看出使用softfp模式。
三. 拓展閱讀
下文闡述了ARM代碼編譯時的軟浮點(soft-float)和硬浮點(hard-float)的編譯以及鏈接實現時的不同。從VFP浮點單元的引入到軟浮點(soft-float)和硬浮點(hard-float)的概念
VFP (vector floating-point)
從ARMv5開始，就有可選的 Vector Floating Point (VFP) 模塊，當然最新的如 Cortex-A8, Cortex-A9 和 Cortex-A5 可以配置成不帶VFP的模式供晶元廠商選擇。
VFP經過若干年的發展，有VFPv2 (一些 ARM9 / ARM11)、 VFPv3-D16（只使用16個浮點寄存器，默認為32個）和VFPv3+NEON (如大多數的Cortex-A8晶元) 。對於包含NEON的ARM晶元，NEON一般和VFP公用寄存器。
硬浮點Hard-float
編譯器將代碼直接編譯成發射給硬體浮點協處理器（浮點運算單元FPU）去執行。FPU通常有一套額外的寄存器來完成浮點參數傳遞和運算。
使用實際的硬體浮點運算單元FPU當然會帶來性能的提升。因為往往一個浮點的函數調用需要幾個或者幾十個時鍾周期。
軟浮點 Soft-float
編譯器把浮點運算轉換成浮點運算的函數調用和庫函數調用，沒有FPU的指令調用，也沒有浮點寄存器的參數傳遞。浮點參數的傳遞也是通過ARM寄存器或者堆棧完成。
現在的Linux系統默認編譯選擇使用hard-float，即使系統沒有任何浮點處理器單元，這就會產生非法指令和異常。因而一般的系統鏡像都採用軟浮點以兼容沒有VFP的處理器。
armel ABI和armhf ABI
在armel中，關於浮點數計算的約定有三種。以gcc為例，對應的-mfloat-abi參數值有三個：soft,softfp,hard。
soft是指所有浮點運算全部在軟體層實現，效率當然不高，會存在不必要的浮點到整數、整數到浮點的轉換，只適合於早期沒有浮點計算單元的ARM處理器；
softfp是目前armel的默認設置，它將浮點計算交給FPU處理，但函數參數的傳遞使用通用的整型寄存器而不是FPU寄存器；
hard則使用FPU浮點寄存器將函數參數傳遞給FPU處理。
需要注意的是，在兼容性上，soft與後兩者是兼容的，但softfp和hard兩種模式不兼容。
默認情況下，armel使用softfp，因此將hard模式的armel單獨作為一個abi，稱之為armhf。
而使用hard模式，在每次浮點相關函數調用時，平均能節省20個CPU周期。對ARM這樣每個周期都很重要的體系結構來說，這樣的提升無疑是巨大的。
在完全不改變源碼和配置的情況下，在一些應用程序上，使用armhf能得到20%——25%的性能提升。對一些嚴重依賴於浮點運算的程序，更是可以達到300%的性能提升。
Soft-float和hard-float的編譯選項
在CodeSourcery gcc的編譯參數上，使用-mfloat-abi=name來指定浮點運算處理方式。-mfpu=name來指定浮點協處理的類型。
可選類型如fpa，fpe2，fpe3，maverick，vfp，vfpv3，vfpv3-fp16，vfpv3-d16，vfpv3-d16-fp16，vfpv3xd，vfpv3xd-fp16，neon，neon-fp16，vfpv4，vfpv4-d16，fpv4-sp-d16，neon-vfpv4等。
使用-mfloat-abi=hard (等價於-mhard-float) -mfpu=vfp來選擇編譯成硬浮點。使用-mfloat-abi=softfp就能兼容帶VFP的硬體以及soft-float的軟體實現，運行時的連接器ld.so會在執行浮點運算時對於運算單元的選擇，
是直接的硬體調用還是庫函數調用，是執行/lib還是/lib/vfp下的libm。-mfloat-abi=soft （等價於-msoft-float）直接調用軟浮點實現庫。
在ARM RVCT工具鏈下，定義fpu模式：
–fpu softvfp
–fpu softvfp+vfpv2
–fpu softvfp+vfpv3
–fpu softvfp+vfpv_fp16
–fpu softvfp+vfpv_d16
–fpu softvfp+vfpv_d16_fp16.
定義浮點運算類型
–fpmode ieee_full : 所有單精度float和雙精度double的精度都要和IEEE標准一致，具體的模式可以在運行時動態指定；
–fpmode ieee_fixed ： 舍入到最接近的實現的IEEE標准，不帶不精確的異常；
–fpmode ieee_no_fenv ：舍入到最接近的實現的IEEE標准，不帶異常；
–fpmode std ：非規格數flush到0、舍入到最接近的實現的IEEE標准，不帶異常；
–fpmode fast ： 更積極的優化，可能會有一點精度損失。
7. Qt交叉編譯遇到的問題
QT相關的安裝軟體包：
(1) tmake-1.13.tar.gz （編譯工具，如progen與tmake）
(2) qt-embedded-2.3.7.tar.gz （提供了qte的庫）
(3) qt-x11-2.3.2.tar.gz （為了生成相應的QT工具，如designer和qvfb等）
(4) qtopia-free-1.7.0.tar.gz （QTE的桌面環境程序）
(5) cross-3.3.2.tar.bz2 （交叉編譯工具）
一、安裝工具
1 安裝 tmake
在 Linux 命令模式下運行以下命令:
tar xfz tmake-1.11.tar.gz
export TMAKEDIR=$PWD/tmake-1.11
export TMAKEPATH=$TMAKEDIR/lib/qws/linux-x86-g++
export PATH=$TMAKEDIR/bin:$PATH
2 安裝 Qt/Embedded 2.3.7
在 Linux 命令模式下運行以下命令:
tar xfz qt-embedded-2.3.7.tar.gz
cd qt-2.3.7
export QTDIR=$PWD
export QTEDIR=$QTDIR
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
./configure –qconfig local–qvfb -depths 4,8,16,32
make sub-src
cd ..
上述命令 ./configure -qconfig -qvfb -depths 4,8,16,32 指定 Qt 嵌入式開發包生成虛擬緩沖幀工具qvfb,並支持 4,8,16,32 位的顯示顏色深度。另外我們也可以在 configure 的參數中添加-system-jpeg 和 gif,使 Qt/Embedded 平台能支持 jpeg、gif 格式的圖形。
上述命令 make sub-src 指定按精簡方式編譯開發包,也就是說有些 Qt 類未被編譯。Qt 嵌入式開發包有 5種編譯范圍的選項,使用這些選項,可控制 Qt 生成的庫文件的大小,但是您的應用所使用到的一些 Qt 類將可能因此在 Qt 的庫中找不到鏈接。編譯選項的具體用法可運行./configure -help 命令查看。
在這一過程的configure中出現了問題：有一個變數沒有聲明，發現是少了一個頭文件，加上即可，make順利通過，看到了enjoy！
3 安裝 Qt/X11 2.3.2
在 Linux 命令模式下運行以下命令:
tar xfz qt-x11-2.3.2.tar.gz
cd qt-2.3.2
export QTDIR=$PWD
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
./configure -no-opengl
make
make -C tools/qvfb
mv tools/qvfb/qvfb bin
cp bin/uic $QTEDIR/bin
cd ..
根據開發者本身的開發環境,也可以在 configure 的參數中添加別的參數, 比如-no-opengl 或-no-xfs,可以鍵入./configure -help 來獲得一些幫助信息。
在這個安裝過程中也出現了很多錯誤，典型的就是在make過程中：
/usr/local/qt-2.3.2/include/qvaluestack.h:57: error: cannot convert 'QValueListIterator<QMap<QString, QString> >' to 'const char*' for argument '1' to 'int remove(const char*)'
/usr/local/qt-2.3.2/include/qvaluestack.h: In member function 'T QValueStack<T>::pop() [with T = QString]':
xml/qxml.cpp:2502: instantiated from here
/usr/local/qt-2.3.2/include/qvaluestack.h:57: error: cannot convert 'QValueListIterator<QString>' to 'const char*' for argument '1' to 'int remove(const char*)'
make[2]: *** [xml/qxml.o] Error 1
make[2]: Leaving directory `/usr/local/qt-2.3.2/src'
make[1]: *** [sub-src] Error 2
make[1]: Leaving directory `/usr/local/qt-2.3.2'
make: *** [init] Error 2
這個錯誤是說，在文件qvaluestack.h的57行出錯。改正方法是修改文件qt-2.3.2/ include/qvaluestack.h的 第57行，將remove( this->fromLast() );改為 this->remove( this->fromLast() );
修改時可能要更改文件許可權，變成可寫的，chmod 666 qvaluestack.h。然後make順利通過，看到了enjoy。
二、交叉編譯 Qt/Embedded 的庫
開發居於 Qt/Embedded 的應用程序要使用到 Qt/Embedded 的庫,編寫的 Qt 嵌入式應用程序最終是在YLE270開發板上運行的,因此在把 Qt 嵌入式應用程序編譯成支持 YLE270 的目標代碼之前,需要兩樣東西,一個是 arm9 的 linux 編譯器,另一個是經 arm9 的linux 編譯器編譯過的 Qt/Embedded 的庫。安裝交叉編譯工具 cross-3.3.2 前面已經安裝過了。
這一步主要是配置 Qt/Embedded2.3.7 的安裝，Qt/Embedded 的安裝選項有很多個,您可以在命令行下直接輸入「./configure」來運行配置,這時安裝程序會一步一步提示你輸入安裝選項。您也可以在「./configure」後輸入多個安裝選項直接完成安裝的配置。在這些選項中有一個選項決定了編譯 Qt/Embedded 庫的范圍,即可以指定以最小,小,中,大,完全 5 種方式編譯 Qt/Embedded 庫。另外 Qt/Embedded 的安裝選項還允許我們自己定製一個配置文件,來有選擇的編譯 Qt/Embedded 庫,這個安裝選項是「-qconfig local」 ;當我們指定這個選項時,Qt/Embedded庫在安裝過程中會尋找qt-2.3.7/src/tools/qconfig-local.h 這個文件,如找到這個文件,就會以該文件裡面定義的宏,來編譯鏈接 Qt/Embedded 庫。
具體過程如下:
cd qt-2.3.7
export QTDIR=$PWD
export QTEDIR=$QTDIR
make clean
./configure –xplatform linux-arm-g++ -shared –debug (接下行)
-qconfig local -qvfb -depths 4,8,16,32
make
cd ..
在make中出現了錯誤，有變數沒有聲明，原來是優龍公司為了避免初學者在一開始就直接接觸到 Qt/Embedde 的復雜的宏編譯選項,把這些宏定義到一個名為 qconfig-local.h的安裝配置文件中,在安裝 Qt/Embedded 的時候,需要把這個文件復制到 Qt/Embedded 的安裝路徑的/src/tools 子路徑下，
cp /配置文件所在路徑/qconfig-local.h ./src/tools
make順利通過，看到了enjoy。
最後就可以在命令行下輸入make 命令對整個工程進行編譯鏈接了，在這里，要把過程中產生的文件放在同一個文件夾裡面，方便應用。
在最後make完畢以後我還是遇到了一個問題，就是生成的可執行文件不能運行，運行時提示：./hello cannot execute binary file,當然不能直接在自己的主機上運行了，因為生成的二進制文件要下到板子上運行的。接上液晶屏，板子上電，把生成的可執行文件下載到板子上，要chmod一下，不然許可權不夠，終於在液晶屏上看到了自己弄的小程序，好開心！
三、添加一個 Qt/Embedded 應用到 QPE
以hello，world！為例
1 在工作的機器上解包 qtopia
tar zxvf qtopia-free-1.7.x.tar.gz
cd qtopia-free-1.7.x
export QTDIR=$QTEDIR
export QPEDIR=$PWD
export PATH=$QPEDIR/bin:$PATH
注意在上面已經設定環境變數 QPEDIR 為 QPE 的安裝(解包)路徑。
2 建立 Hello,World 的例子程序的圖標文件
方法是:製作一個 32 X 32 大小的 PNG 格式的圖標文件,將該文件存放在$QPEDIR/pics/inline 目錄下,然後使用以下命令將$QPEDIR/pics/inline 目錄下的所有圖形文件轉換成為一個 c 語言的頭文件,這個頭文件包含了該目錄下的圖形文件的 rgb 信息。
qembed --images $QPEDIR/pics/inline/*.*
> $QPEDIR/src/libraries/qtopia/inlinepics_p.h
3 交叉編譯 qtopia
在$QPEDIR 路徑下,運行以下命令
cd src
./configure –platform linux-arm-g++
make
cd ..
在這一過程中也出現了比較大的錯誤，在make的時候又出現了error，是resource.cpp的174行的變數qembed_findImage沒有聲明，考慮到以前遇到的情況，推斷可能是少了某個頭文件，但是又不知道是哪一個，google了很久都沒有找到解決辦法，沒辦法只好點開src/libraries/qtopia下面的每一個頭文件看了一遍，還是沒有發現有含有這個變數的文件，繼續google，然後發現了inlinepics_p.h中包含qembed_findImage，於是vi /usr/local/qtopia-free-1.7.0/src/libraries/qtopia/inlinepics_p.h，發現inlinepics_p.h是空白的，原來是
qembed --images $QPEDIR/pics/inline/*.*
> $QPEDIR/src/libraries/qtopia/inlinepics_p.h
出了錯誤，重新操作一遍這一步，再查看inlinepics_p.h，發現正常了，要繼續交叉編譯qtopia：
make clean
./configure –platform linux-arm-g++