交叉編譯時間一般多久

㈠ cmake使用的編譯器和交叉編譯時候的一致么

一致的
下載cmake 然後解壓縮，進入解壓縮後的目錄，依次執行
# ./bootstrap
# make && make install
安裝過程需要幾分鍾。
二 構建交叉編譯的CMakeLists.txt
說明：
設置交叉編譯之前，必須在CMakeList.txt前面加上這樣一句，這樣CMake才會認為你是要交叉編譯：
SET(CMAKE_SYSTEM_NAME linux)
在通知CMake要交叉編譯以後，還要告訴CMake到哪個路徑下去找庫文件，因為在交叉編譯的時候CMake是不會自動去系統默認的目錄找庫文件和頭文件的：
SET(CMAKE_FIND_ROOT_PATH "編譯器環境路徑")
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
其中猜早的第一行，是告訴CMake查找的根目錄是什麼。後面分別是告訴CMake怎麼查找編譯時候的工具程序的位置、庫的位置和頭文件的位置。設置為NEVER表示不查找，設置為ONLY表示只在CMAKE_FIND_ROOT_PATH設定的目錄下查找，設置為BOTH(這是默認選項)表示既可以在寬雹系統目錄下查找，也可以在CMAKE_FIND_ROOT_PATH下查找。因為咱們是交叉編譯，所以後兩項的設置了ONLY，對於編譯時調用工具，一般來說是需要在系統目錄下查找的，不過我不需要所以設慎兆帆置為NEVER。
然後，設置編譯器：
SET(CMAKE_C_COMPILER "編譯器環境路徑"
直接把編譯器的路徑設置過去就可以了，CMAKE_C_COMPILER是C語言編譯器，CMAKE_CXX_COMPILE是C++語言編譯器。

㈡ 北大青鳥設計培訓：怎樣才能提高python運行效率

python逐漸走入人們的視線，成為熱門編程語言，隨之而來，加入python培訓的准程序員大軍也成為社會熱點。
Python具有許多其他編程語言不具備的優勢，譬如能通過極少量代碼完成許多操作，以及多進程，能夠輕松支持多任務處理。
除了多種優勢外，python也有不好的地方，運行較慢，下面電腦培訓http://www.kmbdqn.cn/為大家介紹6個竅門，可以幫你提高python的運行效率。
1.在排序時使用鍵Python含有許多古老的排序規則，這些規則在你創建定製的排序方法時會佔用很多時間，而這些排序方法運行時也會拖延程序實際的運行速度。
最佳的排序方法其實是盡可能多地使用鍵和內置的sort()方法。
2.交叉編譯你的應用開發者有時會忘記計算機其實並不理解用來創建現代應用程序的編程語言。
計算機理解的是機器語言。
為了運行你的應用，你藉助一個應用將你所編的人類可讀的代碼轉換成機器可讀的代碼。
有時，你用一種諸如Python這樣的語言編寫應用，再以C++這樣的語言運行你的應用，這在運行的角度來說，是可行的。
關鍵在於，你想你的應用完成什麼事情，而你的主機系統能提供什麼樣的資源。
3.關鍵代碼使用外部功能包Python簡化了許多編程任務，但是對於一些時間敏感的任務，它的表現經常不盡人意。
使用C/C++或機器語言的外部功能包處理時間敏感任務，可以有效提高應用的運行效率。
這些功能包往往依附於特定的平台，因此你要根據自己所用的平台選擇合適的功能包。
簡而言之，這個竅門要你犧牲應用的可移植性以換取只有通過對底層主機的直接編程才能獲得的運行效率。
4.針對循環的優化每一種編程語言都強調最優化的循環方案。
當使用Python時，你可以藉助豐富的技巧讓循環程序跑得更快。
然而，開發者們經常遺忘的一個技巧是：盡量避免在循環中訪問變數的屬性。
5.嘗試多種編碼方法每次創建應用時都使用同一種編碼方法幾乎無一例外會導致應用的運行效率不盡人意。
可以在程序分析時嘗試一些試驗性的辦法。
譬如說，在處理字典中的數據項時，你既可以使用安全的方法，先確保數據項已經存在再進行更新，也可以直接對數據項進行更新，把不存在的數據項作為特例分開處理。
6.使用較新的Python版本你要保證自己的代碼在新版本里還能運行。
你需要使用新的函數庫才能體驗新的Python版本，然後你需要在做出關鍵性的改動時檢查自己的應用。
只有當你完成必要的修正之後，你才能體會新版本的不同。

㈢ 什麼是交叉編譯，為什麼要採用交叉編譯

在一個平台架構上，編譯另一個平台架構的可執行代碼，就是交叉編譯。
例如在x86架構的PC上編譯arm嵌入式設備的可執行程序。
交叉編譯是不得不用，
首先在目標設備的系統還沒引導起來的時候，編譯目標平台的引導程序，顯然只能交叉編譯。
還有因為目標設備往往能力太低，沒法安裝編譯器，或者勉強安裝了，也慢得像蝸牛。

㈣ 什麼是交叉編譯，為什麼要使用交叉編譯

交叉編譯的概念（來自網路）：

簡單地說，就是在一個平台上生成另一個平台上的可執行代碼。同一個體系結構可以運行不同的操作系統；同樣，同一個操作系統也可以在不同的體系結構上運行。舉例來說，我們常說的x86 Linux平台實際上是Intel x86體系結構和Linux for x86操作系統的統稱；而x86 WinNT平台實際上是Intel x86體系結構和Windows NT for x86操作系統的簡稱。
舉個例子：
我們在Linux系統比如Ubuntu上編寫的C程序完全可以拿到Windows系統上正常運行。

㈤ 如何編譯Android的kernel

1.准備工作： （ubuntu1110 32位）
ubuntu等linuxOS，下載好eclipse，安裝好JDK， 安裝好android的SDK， 在eclipse中成功打開android 手機模擬器即OK。

2.初始化編譯環境 ：
關注該網頁上的「installing required packages」,其中有的軟體包因為版本問題而安裝不上，不用管它，之後遇到錯誤再單獨解決。

3.下載內核源碼：
android 2.3 內核 下載需要等待一段時間。

4.下載交叉編譯器：
該步驟有可能耗費大量時間，依據網速不同，幾個小時到幾天不等，或許可以嘗試git clone 後面的地址只下載prebuilt/linux-x86/toolchain

5.設置參數以及編譯：
$ export ARCH=arm
$ export SUBARCH=arm
$ export CROSS_COMPILE=arm-eabi-
$ cd goldfish // 進入下載的源代碼目錄
$ git checkout <commit_from_first_step> //這個步驟我沒有做，不知道幹嘛用的
$ make goldfish_defconfig
$ make

6.報錯信息：
若有報錯說找不到 （arm-eabi-gcc command not found）等等，嘗試使用採用另外一個交叉編譯器。

7.測試：

最後，測試一下剛才編譯的內核：emulator -avd myavd -kernel ~/goldfish/arch/arm/boot/zImageemulator若系統找不到，可以去android SDK中某文件夾找到，加入系統PATH即可。 -avd後面的參數 myavd即為模擬器的名字，這個我是在eclipse中的模擬器管理中新建的一個模擬器，用那個模擬器的名字即可。 -kernel後面的參數就找到剛才編譯出的內核的路徑。
若啟動模擬器失敗，可嘗試關閉後再啟動。第一次啟動模擬器時可能需要等待比較長的時間。

㈥ 如何使用Docker構建運行時間較長的腳本

問題
讓我們從這個我試圖解決的問題開始。我開發了一個會運行很長時間的構建腳本，這個腳本中包含了很多的步驟。
這個腳本會運行1-2個小時。
它會從網路下載比較大的文件（超過300M）。
後面的構建步驟依賴前期構建的庫。
但最最煩人的是，運行這個腳本真的需要花很長的時間。
文件系統是固有狀態
我們一般是通過一種有狀態的方式與文件系統進行交互的。我們可以添加、刪除或移動文件。我們可以修改文件的 許可權或者它的訪問時間。大部分獨立的操作都可以撤銷，例如將文件移動到其它地方後，你可以將文件恢復到原來的位置。但我們不會通過快照的方式來將它恢復到 原始狀態。這篇文章我將會介紹如何在耗時較長的腳本中充分利用快照這一特性。
使用聯合文件系統的快照
Docker使用的是聯合文件系統叫做AUFS（譯者註：簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統下的文件系統）。聯合文件系統實現了Union mount。顧名思義，也就是說不同的文件系統的文件和目錄可以分層疊加在單個連貫文件系統之上。這是通過分層的方式完成的。如果一個文件出現在兩個文件系統，那最高層級的文件才會顯示（該文件其它版本也是存在於層級中的，不會改變，只是看不到的）。
在Docker中，每一個在Union mount轉哦給你的文件系統都被稱為layers（層）。使用這種技術可以輕松實現快照，每個快照都是所有層的一個Union mount。
生成腳本的快照
使用快照可以幫助構建一個長時運行的腳本。總的想法是，將一個大的腳本分解為許多小的腳本（我喜歡稱之為 scriptlets），並單獨運行這些小的腳本，腳本運行後為其文件系統打一個快照 （Docker會自動執行此操作）。如果你發現一個scriptlet運行失敗，你可以快速回退到上次的快照，然後再試一次。一旦你完成腳本的構建，並且 可以保證腳本能正常工作，那你就可以將它分配給其它主機。
回過頭來再對比下，如果你沒有使用快照功能了？當你辛辛苦苦等待了一個半小時後，腳本卻構建失敗了，我想除了少部分有耐心的人外，很多人是不想再來一次了，當然，你也會盡最大努力把系統恢復到失敗前的狀態，比如可以刪除一個目錄或運行make clean。
但是，我們可能沒有真正地理解我們正在構建的組件。它可能有復雜的Makefile，它會把把文件放到文件系統中我們不知道的地方，唯一真正確定的途徑是恢復到快照。
使用快照構建腳本的Docker
在本節中，我將介紹我是如何使用Docker實現GHC7.8.3 ARM交叉編譯器的構建腳本。Docker非常適合做這件事，但並非完美。我做了很多看起來沒用的或者不雅的事情，但都是必要的，這都是為了保證將開發腳本的總時間降到最低限度。構建腳本可以在這里找到。
用Dockerfile構建
Docker通過讀取Dockerfile來構建鏡像。Dockerfile會通過一些命令來具體指定應該執行哪些動作。具體使用說明可以參考這篇文章。在我的腳本中主要用到WORKDIR、ADD和RUN。ADD命令非常有用因為它可以讓你在運行之前將外部文件添加到當前Docker鏡像中然後轉換成鏡像的文件系統。你可以在這里看到很多scriptlets構成的構建腳本。
設計
1. 在RUN之前ADD scriptlets
如果你很早就將所有的scriptletsADD在Dockerfile，您可能會遇到以下問題：如果你的腳本構建失敗，你回去修改scriptlet並再次運行docker build。但是你發現，Docker開始在首次加入scriptlets的地方構建！這樣做會浪費了大量的時間並且違背了使用快照的目的。
出現這種情況的原因是由於Docker處理它的中間鏡像（快照）的方式。當Docker通過Dockerfile構建鏡像時，它會與中間鏡像比較當前命令是否一致。然而，在ADD命令的情況下被裝進鏡像的文件里的內容也會被檢查。如果相對於現有的中間鏡像，文件已經改變，那麼Docker也別無選擇，只能從這點開始建立一個新的鏡像。因為Docker不知道這些變化會不會影響到構建。
此外，使用RUN命令要注意，每次運行時它都會導致文件系統有不同的更改。在這種情況下，Docker會發現中間鏡像並使用它，但是這將是錯誤的。RUN命令每次運行時會造成文件系統相同的改變。舉個例子，我確保在我的scriptlets我總是下載了一個已知版本的文件與一個特定MD5校驗。
對Docker 構建緩存更詳細的解釋可以在這里找到。
2.不要使用ENV命令來設置環境變數，請使用scriptlet。
它似乎看起來很有誘惑力：使用ENV命令來設置所有構建腳本需要的環境變數。但是，它不支持變數替換的方式，例如 ENV BASE=$HOME/base 將設置BASE的值為$HOME/base著很可能不是你想要的。
相反，我用ADD命令添加一個名為set-env.sh文件。此文件會包含在後續的scriptlet中：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env-1.sh
如果你沒有在第一時間獲取set-env.sh會怎麼樣呢？它很早就被加入Dockerfile並不意味著修改它將會使隨後的快照無效？
是的，這會有問題。在開發腳本時，我發現，我已經錯過了在set-env.sh添加一個有用的環境變數。解決方案是創建一個新的文件set-env-1.sh包含：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env.sh
if ! [ -e "$CONFIG_SUB_SRC/config.sub" ] ; then
CONFIG_SUB_SRC=${CONFIG_SUB_SRC:-$NCURSES_SRC}
fi
然後，在所有後續的scriptlets文件中包含了此文件。現在，我已經完成了構建腳本，我可以回去解決這個問題了，但是，在某種意義上，它會破壞最初的目標。我將不得不從頭開始運行構建腳本看看這種變化是否能成功。
缺點
一個主要缺點是這種方法是，所構建的鏡像尺寸是大於它實際需求的尺寸。在我的情況下尤其如此，因為我在最後刪除了大量文件的。然而，這些文件都仍然存在於聯合掛載文件系統的底層文件系統內，所以整個鏡像是大於它實際需要的大小至少多餘的是刪除文件的大小。
然而，有一個變通。我沒有公布此鏡像到Docker Hub Registry。相反，我：
使用docker export導出內容為tar文件。
創建一個新的Dockerfile簡單地添加了這個tar文件的內容。
產生尺寸盡可能小的鏡像。
結論
這種方法的優點是雙重的：
它使開發時間降至最低，不再做那些已經構建成功的子組件。你可以專注於那些失敗的組件。
這非常便於維護構建腳本。構建可能會失敗，但只要你搞定Dockerfiel，至少你不必再從頭開始。
此外，正如我前面提到的Docker不僅使寫這些構建腳本更加容易，有了合適的工具同樣可以在任何提供快照的文件系統實現。

㈦ 如何使用CMake進行交叉編譯

cmake交叉編譯配置

很多時候，我們在開發的時候是面對嵌入式平台，因此由於資源的限制需要用到相關的交叉編譯。即在你host宿主機上要生成target目標機的程序。裡面牽扯到相關頭文件的切換和編譯器的選擇以及環境變數的改變等，我今天僅僅簡單介紹下相關CMake在面對交叉編譯的時候，需要做的一些准備工作。

CMake給交叉編譯預留了一個很好的變數CMAKE_TOOLCHAIN_FILE，它定義了一個文件的路徑，這個文件即toolChain，裡面set了一系列你需要改變的變數和屬性，包括C_COMPILER,CXX_COMPILER,如果用Qt的話需要更改QT_QMAKE_EXECUTABLE以及如果用BOOST的話需要更改的BOOST_ROOT(具體查看相關Findxxx.cmake裡面指定的路徑)。CMake為了不讓用戶每次交叉編譯都要重新輸入這些命令，因此它帶來toolChain機制，簡而言之就是一個cmake腳本，內嵌了你需要改變以及需要set的所有交叉環境的設置。

toolChain腳本中設置的幾個重要變數

1.CMAKE_SYSTEM_NAME:

即你目標機target所在的操作系統名稱，比如ARM或者Linux你就需要寫"Linux",如果Windows平台你就寫"Windows",如果你的嵌入式平台沒有相關OS你即需要寫成"Generic",只有當CMAKE_SYSTEM_NAME這個變數被設置了，CMake才認為此時正在交叉編譯，它會額外設置一個變數CMAKE_CROSSCOMPILING為TRUE.

2. CMAKE_C_COMPILER:

顧名思義，即C語言編譯器，這里可以將變數設置成完整路徑或者文件名，設置成完整路徑有一個好處就是CMake會去這個路徑下去尋找編譯相關的其他工具比如linker,binutils等，如果你寫的文件名帶有arm-elf等等前綴，CMake會識別到並且去尋找相關的交叉編譯器。

3. CMAKE_CXX_COMPILER:

同上，此時代表的是C++編譯器。

4. CMAKE_FIND_ROOT_PATH:

指定了一個或者多個優先於其他搜索路徑的搜索路徑。比如你設置了/opt/arm/，所有的Find_xxx.cmake都會優先根據這個路徑下的/usr/lib,/lib等進行查找，然後才會去你自己的/usr/lib和/lib進行查找，如果你有一些庫是不被包含在/opt/arm裡面的，你也可以顯示指定多個值給CMAKE_FIND_ROOT_PATH,比如

set(CMAKE_FIND_ROOT_PATH /opt/arm /opt/inst)

該變數能夠有效地重新定位在給定位置下進行搜索的根路徑。該變數默認為空。當使用交叉編譯時，該變數十分有用：用該變數指向目標環境的根目錄，然後CMake將會在那裡查找。

5. CMAKE_FIND_ROOT_PATH_MODE_PROGRAM:

對FIND_PROGRAM()起作用，有三種取值，NEVER,ONLY,BOTH,第一個表示不在你CMAKE_FIND_ROOT_PATH下進行查找，第二個表示只在這個路徑下查找，第三個表示先查找這個路徑，再查找全局路徑，對於這個變數來說，一般都是調用宿主機的程序，所以一般都設置成NEVER

6. CMAKE_FIND_ROOT_PATH_MODE_LIBRARY:

對FIND_LIBRARY()起作用，表示在鏈接的時候的庫的相關選項，因此這里需要設置成ONLY來保證我們的庫是在交叉環境中找的.

7. CMAKE_FIND_ROOT_PATH_MODE_INCLUDE:

對FIND_PATH()和FIND_FILE()起作用，一般來說也是ONLY,如果你想改變，一般也是在相關的FIND命令中增加option來改變局部設置，有NO_CMAKE_FIND_ROOT_PATH,ONLY_CMAKE_FIND_ROOT_PATH,BOTH_CMAKE_FIND_ROOT_PATH

8. BOOST_ROOT：

對於需要boost庫的用戶來說，相關的boost庫路徑配置也需要設置，因此這里的路徑即ARM下的boost路徑，裡面有include和lib。

9. QT_QMAKE_EXECUTABLE:

對於Qt用戶來說，需要更改相關的qmake命令切換成嵌入式版本，因此這里需要指定成相應的qmake路徑（指定到qmake本身）

toolChain demo

# this is required
SET(CMAKE_SYSTEM_NAME Linux)

# specify the cross compiler
SET(CMAKE_C_COMPILER /opt/arm/usr/bin/ppc_74xx-gcc)
SET(CMAKE_CXX_COMPILER /opt/arm/usr/bin/ppc_74xx-g++)

# where is the target environment
SET(CMAKE_FIND_ROOT_PATH /opt/arm/ppc_74xx /home/rickk/arm_inst)

# search for programs in the build host directories (not necessary)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

# configure Boost and Qt
SET(QT_QMAKE_EXECUTABLE /opt/qt-embedded/qmake)
SET(BOOST_ROOT /opt/boost_arm)

這樣就完成了相關toolChain的編寫，之後，你可以靈活的選擇到底採用宿主機版本還是開發機版本，之間的區別僅僅是一條-DCMAKE_TOOLCHAIN_FILE=./toolChain.cmake，更爽的是，如果你有很多程序需要做轉移，但目標平台是同一個，你僅僅需要寫一份toolChain放在一個地方，就可以給所有工程使用。

㈧ 關於交叉編譯工具鏈的問題

核心轉儲是崩潰報告的一個過程，他只是把當前崩潰的信息轉存出來方便差錯。而且這個核心轉儲幾個字也不過是個提示輸出信息。這個提示不會給與任何與錯誤相關的內容，必須看其他的錯誤信息或者他轉儲出來的東西來分析。
不過核心轉儲，應該是程序運行出錯而崩潰。這種問題出現在你正在運行的程序，而不是編譯過程出現的編譯錯誤（也就是說，出現核心轉儲應該就是 GCC 或者他調用的程序自己崩潰了）。出現這個問題的原因很多。

如果是因為沒有找到某些 header 文件，不應該是核心轉儲錯誤，而是編譯器或者某個過程提示錯誤信息後退出，他會輸出錯誤信息告訴你問題所在。

至於你編譯的這些東西版本都比較老，我建議還是嘗試降級整個系統來編譯、運行你現在的這些東西。或者升級你這個交叉編譯工具鏈到當前主流的版本來用。

至於交叉工具連當中的 GCC 和你當前本機的 GCC，完全是兩個互相獨立的 GCC 。
只是他們編譯輸出的二進製程序針對的指令集不同而已。相對的 binutils 和 glibc 和 kernel-header 都是一樣的意思，針對目標而輸出的相關程序。當然 glibc 和 kernel-header 主要是以「數據」方式存在，gcc 和 binutils 主要是以可以運行的程序方式存在（當然不是絕對的，比如 gcc 還會提供幾個 lib 相關的內容，不過大部分情況下你可以這么理解更直觀了解他們的作用）。
一般說來 GCC 是編譯器，binutils 是連接器，glibc 是標准 C 庫（主要是連接時，連接器必須有目標的函數庫文件，也就是 .so 文件，對應 Windows 是 .dll 文件。連接器把函數調用正確的掛接到對應的函數入口上）。linux header 就是 C 語言常見的 C header 文件和相關的開發數據。一般主要用來編譯 glibc ，glibc 作為中間層來提供內核相關調用。當然程序有些時候也會直接調用內核函數，這樣這些程序在編譯時也需要 kernel 的 header 。

這兩套東西一個輸出你當前 PC 的程序，一個輸出 ARM 的程序。兩個 GCC 套裝之間不能互相替換。只能自己輸出屬於自己的程序。
但是這兩套程序雖然輸出的程序不同，但可以運行的部分，卻都是在你的計算機上運行。而且你本機的 GCC 因為可以輸出本機的程序。所以你需要用他來輸出在你本機運行，但是卻輸出 ARM 程序的 GCC 套裝。

這就好比兩個錘子，一個錘子用來打鐵，一個錘子用來打錫。用途不同，但這兩個錘子都是鐵做的。
你作這個交叉編譯工具鏈，就是用你手裡已經有的打鐵的錘子，打出一個用鐵製作的用來打錫的錘子。這個打錫的錘子是不能打鐵的，同樣這個打鐵的錘子是不能用來打錫的。