多核編譯命令

A. 如何讓gcc支持多核編譯

四核四線程用 make -j5
四核八線程用 make -j9
經常搞大量重復編譯，建議使用ccache

B. 有什麼辦法可以加速make的編譯耗時，以利用到底層的多核硬體

在使用 makefile 工具對多個源程序進行編譯、連接時，首先必須要確保你需要編譯的程序都是正確的，然後將編譯各個源程序按照一定的先後順序寫入到一個 makefile 文件中（預設名稱叫 makefile，但是也可以使用別的文件名），在此編譯過程中，到底哪一個源程序是只編譯、不連接；
哪一個源程序是需要等別的源程序都編譯好了之後，再進行最後的連接，這些都必須寫清楚。

C. vs2010編譯QT4.8.6，designer.exe、assistant.exe無法運行

認真核對操作步驟：
1、修改環境變數工具推薦：Rapid Environment Editor。
修改前請先備份當前的環境變數。然後：
(1)檢查系統變數path，刪除有關mingw其他版本等信息，以免與後續的mingw32-make沖突。
(2)檢查用戶變數INCLUDE、LIB、PATH、MSDevDir和MSVCDir，刪除有關\Microsoft Visual Studio\VC98的信息，因為它們會與後續的mingw32-make沖突，導致編譯出錯。
2、在電腦上安裝mingw編譯器，假設路徑安裝在C:\Qt\mingw32。將C:\Qt\mingw32\bin添加進環境變數path，打開DOS命令行輸入gcc --version和g++ --version和mingw32-make --version驗證編譯器安裝成功。我用的MinGW版本是V4.8.2，
3、解壓qt-everywhere-opensource-src-4.8.6.zip並進入目錄。例如：D:\qt-everywhere-opensource-src-4.8.6\
4、依次執行以下DOS命令：
(1)configure -debug-and-release -opensource -prefix "D:\Qt4.8.6" -platform win32-g++ -nomake demos -nomake examples
常見的使用選項說明：
-debug-and-release 編譯debug和release版
-opensource 選擇開源協議並確認
-platform win32-g++ 使用mingw編譯
-prefix "D:\Qt4.8.6" 指定編譯結果目錄,如果未指定則默認當前
-shared 創建和使用共享Qt庫
-static 創建和使用靜態Qt庫
-nomake demos -nomake examples 不編譯常式
-nomake tests 不編譯tests

-skip qtwebkit 忽略qtwebkit，因為編譯它特別消耗時間

-mp 使用多核優化編譯

(2)mingw32-make
(3)mingw32-make install
5、編譯完成後，把C:\Qt\mingw32\bin\路徑下的三個文件libgcc_s_dw2-1.dll、libstdc++-6.dll和libwinpthread-1.dll拷貝到D:\qt-everywhere-opensource-src-4.8.6\bin\。另外，也請把步驟1備份的環境變數還原。
6、修改Qt安裝路徑
最初編譯時選擇的路徑是D:\Qt4.8.6\。如果想將它復制到其他盤符，並且改名，例如：C:\Qt\4.8.6_MinGW。這樣一來會有問題嗎？是的，會有問題，因為Qt有絕對路徑依賴症。改名後C:\Qt\4.8.6_MinGW\bin\的exe執行程序都會出問題，要麼程序打不開，要麼多國語言發生異常。用記事本打開C:\Qt\4.8.6_MinGW\bin\qmake.exe，查找關鍵字「qt_prfxpath」，可以看到裡面含有原始的安裝路徑。我們不可以手動去修改qmake.exe，真正有效的解決方法是：
在C:\Qt\4.8.6_MinGW\bin\路徑下創建一個qt.conf文件，內容為
[paths]
Prefix = C:/Qt/4.8.6_MinGW

請注意：qt.conf文件必須是ANSI格式，並且Prefix的斜杠風格採取的是linux的，而非Windows，否則會失效。或者使用"Prefix = .. "，如此一來，任意路徑有效。

D. 怎樣ubuntu環境下編譯內核詳解

步驟/方法
一、下載源代碼和編譯軟體的准備
下載內核源代碼：http://www.kernel.org/
注意，點擊2.6.25內核的F版，即完整版。
如果你懶得去網站點聯接，運行下列命令：
代碼:$cd ~$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.10.tar.bz2
安裝有關編譯程序。安裝make ,gcc, make-kpkg,運行menuconfig等等和編譯內核相關的工具。安裝不了，請檢查/etc/apt/sources.list 文件。有關命令：代碼:$sudo apt-get install build-essential kernel-package libncurses5-dev
二、解壓源代碼注意，網上很多教程上說應該解壓到 /usr/src,純屬以訛傳訛，linux掌門人linus說解壓到任何目錄上都可以。當然，linus的說法是正確的。我放在自己的主目錄下的src目錄。如果你下載源代碼是放到自己的主目錄下或者運行上面的wget下載的，那麼運行下列命令：代碼:$ cd ~$ mkdir src && tar jfx linux-2.6.25.10.tar.bz2 -C src/現在，源代碼就在 ~/src/linux-2.6.25.10進入源代碼的目錄，准備下一步的工作。後面都在這個目錄裡面進行。代碼:$ cd ~/src/linux-2.6.25.10
三、開始編譯前的准備工作。首先，清理以前編譯時留下的臨時文件。如果是剛剛解開的包，不需要執行這步。如果是第二次或者是第n次編譯，那麼一定要執行。相關命令如下：代碼:$ sudo make mrproper網上很多教程上說把現在使用的內核的config拷貝過來參考，據實驗，是不需要的，ubuntu還有debian會自動做這步。不過這條命令倒是可以學習一下。當然你可以將以前的配置拷貝過來。命令：代碼:cp /boot/config-`uname -r` ./.config
四、開始配置內核選項。相關命令：代碼:$sudo make menuconfig配置用到的鍵只有幾個，esc退出菜單;空格改變選項狀態;游標鍵上下左右移動,回車選定。選項意義：M是編譯成可以隨時加入的模塊，*是編譯進入內核，空就是不要。配置選項非常多，具體配置可以參考金步國先生翻譯的資料：Linux 2.6.19.x 內核編譯配置選項。參考網址：http://lamp.linux.gov.cn/Linux/kernel_options.html為了一次成功，請大家遵循一個原則，如果你自己使用的內核已經選用了某個選項，如果你沒用充分的理由，不要隨便改動。這樣雖然內核不那麼精簡，但是不容易出現問題。我們可以精簡的部分是硬體模塊部分，對於自己沒有的硬體要毫不猶豫的清除。如果你很執著，或者你有潔癖，你也可以一項項對過去，按照金步國先生的資料描述去選擇基本上沒有問題。
五、必須強調的幾個選項:1、
在「General setup」裡面的「Prompt for development and/or incomplete
code/drivers」金步國認為是不需要。但是如果你的硬體比較新，那幾乎是必須選的，這樣，我們才可以找到4965無線網卡，alsa聲音驅動等
等。Kernel log buffer size 我選15，雙核。如果你用ia64，要選16。Control Group support 集群支持？可以不要Choose SLAB allocator (SLUB (Unqueued Allocator)) 內存管理模式slab和slub選擇slub。
2、在「Block layer」里，假如沒有2TB的硬碟，就去掉：Support for Large Block Devices 。Support for Large Single Files 也不需要，誰有2TB的文件？
3、Processor type and features中是關於cpu的，要認真選。Symmetric multi-processing support是打開多核的開關，我的cpu是雙核的，選中。Processor family (Core 2/newer Xeon) 我的是Core 2/newer Xeon。找到自己的cpu後，把Generic x86 support選項取消。Subarchitecture Type 選(PC-compatible)Maximum number of CPUs 輸入自己的核心數目，我輸入2。SMT (Hyperthreading) scheler support說的是超線程技術，P4有支持的，我的t8100不支持，目前大部分市場上的家用cpu都不支持。High Memory Support (4GB) 1G以下選1G；我是3G，選4G；4G以上的選16G在「 Timer frequency 」里，默認是250Hz，較新的cpu都可以選擇了1000Hz，性能更好。
4、Power management options中把APM (Advanced Power Management) BIOS support關閉。現在的電腦都用acpi了。CPU Frequency scaling 是筆記本cpu節電技術Default CPUFreq governor (conservative) cpu節電模式有四個，筆記本默認選conservative比較好。ACPI Processor P-States driver 必須選，不然CPU Frequency就不能用。後面的可選自己硬體相關的，我選的是Intel Enhanced SpeedStep和 Intel Speedstep on ICH-M chipsets，其他的統統消滅。
5、Bus options的選擇：Bus options (PCI, PCMCIA, EISA, MCA, ISA)PCI support PCI Express support 現在新買的機器基本上都是PCI Express了ISA support 較新的新機器沒有ISA設備，可以去掉MCA support 去掉NatSemi SCx200 support 去掉PCI Hotplug Support Support for PCI Hotplug (EXPERIMENTAL) 如果沒有PCI熱插拔設備，去掉這里的選項可以考慮全部編譯進內核，而不是以模塊形式存在。
6、Device Drivers是重點，由於linux不但面向個人工作站，更多的是面向伺服器的應用，所以可以把自己機器上沒有的硬體全部去掉，而不用面面俱到。但是通用型的選項要慎重。比如在網卡的部分，除了我的千兆網卡 Broadcom Tigon3 support和4965無線網卡Intel Wireless WiFi 4965AGN，其餘的硬體支持統統去掉。再比如音效卡部分，我的是hd音效卡，我只是在PCI devices中，選intel hd 音效卡，再選Build IDT/Sigmatel HD-audio codec support，除此之外的硬體支持全部去掉。
音效卡還有一個細節，在ubuntu7.10裡面， 需要在/etc/modprobe.d/alsa-base後面添加options
snd-hda-intel probe_mask=1
model=3stack，這樣我的筆記本喇叭才可以發聲，不然只有外接耳機或者音箱。這次編譯以後，這個動作就不必了，但是兩個耳機插口只有一個可以用
了。再比如我的電腦中沒有agp，就可以直接把agp相關的選項全部取消。要注意的：ATA/ATAPI/MFM/RLL support Include IDE/ATA-2 DISK support 如果你的/boot是放在IDE硬碟上，那麼這里一定要選＊，選M都不行。否則啟動時會出現「waiting for root file system」的提示而停滯不前。 SCSI emulation support 要用刻錄機，必須選。SCSI device support 現在都是SATA硬碟，一定要選＊ SCSI disk support 如果你的/boot放在SATA硬碟上，一定要選＊。
SCSI CDROM support 雖然康寶刻錄機是ide介面的，但是必須把它當成scsi介面的，這是老問題了。用刻錄機，必須選。
Graphics supportSupport for frame buffer devices 選中，進入選擇 VESA VGA graphics support 選上，不然字元界面啟動會有問題，後面的顯卡選擇：由於我的顯卡是nvidia 8400gs，要自己安裝nvidia公司的驅動，所以一個都沒有選。這樣導致ubuntu開機動畫會出問題，我索性在grub中的splash字元全部刪除，把開機動畫關閉。字元界面很正常。 Console display driver support 有人開機後字元控制台錯誤，就是這部分選項沒有選，出問題了。 Framebuffer Console support 需要打開。
Bootup logo 開機圖標，會在自檢的畫面上加上個性圖標。需要在grub上添加「vga＝」的選項，可以參考http://dotimes.com/articles /t23-slackware-framebuffer.html7、File systemsFilesystem in Userspace support 簡稱fuse。是必選的，如果你要用windows分區。
CD-ROM/DVD Filesystems ISO 9660 CDROM file system support 一般選＊DOS/FAT/NT Filesystems VFAT (Windows-95) fs support 有FAT32分區就選＊吧 NTFS file system support 有NTFS分區就選＊吧 NTFS write support 如果想對 NTFS分區進行寫操作，選＊必須將啟動盤的文件系統編譯進內核，默認是編譯成模塊，這樣無法啟動系統。ubuntu採用的文件系統是ext3,請把ext2,ext3相關的必要選項都編譯進入內核。
8、Virtualization這個大類是我多花幾百元買t8100的主要原因，因為t8100支持intel vt技術使linux上的虛擬機的性能大幅度提高。這里的選項我除了amd的，其他都編譯成模塊。
9、全部設置完成，最後一項是保存設置。按照我的習慣，先在上一層目錄保存一個備份，文件名類似 ../config20080630然後再保存到當起目錄,文件名 .config退出設置程序。
六、開始編譯內核。ubuntu的工具是make-kpkg,和其他的發行版相比，步驟相對簡單。相關命令:代碼:$sudo make-kpkg clean 這條命令好像不要超級許可權，很多資料上說要，不過這不是原則問題。
$ sudo make-kpkg -initrd --initrd --append-to-version=dell1400 kernel_image kernel-headers上述命令中的dell1400可以用自己喜歡的字元代替，最後的字元一定是數字.輸完上述命令回車之前，建議大家把瀏覽器還有別的運用程序都關掉，機器開始的工作比較艱苦。
我的機器大概十幾分鍾。
七、安裝內核編譯完成就是安裝工作。編譯好的內核在上一層目錄。包括linux-headers-...-_i386.deb和linux-image-...-i386.deb兩個文件，如果你不搞開發的話，只要安裝內核就可以，頭文件以後要用的時候再說。安裝相關命令：
代碼:$ cd ..$ sudo dpkg -i linux-image-（按tab鍵）文件名很長，如果不用tab自動補足是不可能的，tab鍵萬歲。安裝完成後和老內核比較一下大小代碼:
$ ls -l /boot/
八、重新啟動驗證新內核。代碼:$ sudo reboot
九、顯卡驅動如果你的顯卡和我一樣是nvidia顯卡，啟動之後往往無法正常進入x－window。即使能看到gdm登錄界面，效果也是很差的。那麼就要安裝nvidia驅動。用ctrl+alt+f1 進入字元命令行，輸入用戶名，密碼登錄。命令：代碼:下載驅動$ wget http://us.download.nvidia.com/XFree86/Linux-x86/173.14.12/NVIDIA-Linux-x86-173.14.12-pkg1.run$sudo －s輸入密碼取得超級許可權。＃ps ax看看和gdm相關的進程，把這些進程全部關閉;用sudo /etc/init.d/gdm stop有可能有一個進程沒有關閉：＃kill 進程號然後安裝nvidia顯卡驅動,當然驅動要先下好，到nvidia驅動所在的目錄里，運行：＃ sh ./NVIDIA-Linux-x86-173.14.12-pkg1.run重新啟動以後就ok。要用nvidia的驅動，每次升級內核都要這么做。
十、無線網卡相關的內核選項是Networking --->Wireless --->Generic IEEE 802.11 Networking Stack (mac80211)還有4965的驅動。4965
無線網卡驅動雖然已經編入內核，但沒有firmware無法使用。需要把原來內核的firmware拷貝到新內核對應的目錄，名字和內核一致,我的內核是
linux－image-2.6.25.10dell1400，那建的目錄名就是2.6.25.10dell1400。代碼:具體命令：$ cd /lib/firmware/$ sudo mkdir 2.6.25.10dell1400把你的老內核中的4965的firmware拷貝過來。$ sudo cp 2.6.24-16-generic/* 2.6.25.10dell1400/上面的命令和下面的命令是等價的：$ cd /lib/firmware/$ sudo cp -R 2.6.24-16-generic/ 2.6.25.10dell1400/
重新啟動系統，無線網卡就正常了。
附編譯使用的機器配置：dell vostro 1400,t8100,nvidia 8400cs顯卡，內置SigmaTel STAC9228晶元的音效卡，4965無線網卡，BCM5906M千兆網卡，3G內存,160G硬碟,combo刻錄。
編譯系統版本：ubuntu 8.04桌面版.

E. android系統編譯能用分布式編譯嗎

項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。

tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾，也許這個數字是有點誇張了，不過粗想想，把文件放到內存上做編譯應該是比在磁碟上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低，在Linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度：
用物理磁碟：40分16秒
用tmpfs：39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對於大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數，可以把項目在進行並行編譯，比如在一台雙核的機器上，完全可以用make -j4，讓make最多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。
還是用Kernel來測試：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看來，在多核CPU上，適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守，則可能本身編譯的可並行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。

ccache用於把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然後再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說，也是一樣。為什麼不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種「聰明」的方案根本不能正常工作，只有每次make clean再make才行。
安裝完ccache後，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了（通常情況下/usr/local /bin會在PATH中排在/usr/bin前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒

看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

F. android 怎樣編譯kernel 命令 make

方法如下：
在Linux的環境下:
建立目錄:

mkdir ~/android-kernel cd android-kernel

下載源代碼, 大概有280MB, 慢慢等哈~~~ (當然你要先安裝git) git clone git://git.linuxtogo.org/home/groups/mobile-linux/kernel.git
類似的屏幕信息:
Initialized empty Git repository in /home/user/android-kernel/kernel/.git/ remote: Counting objects: 908251, done.
remote: Compressing objects: 100% (153970/153970), done.
remote: Total 908251 (delta 755115), reused 906063 (delta 753016) Receiving objects: 100% (908251/908251), 281.86 MiB | 292 KiB/s, done. Resolving deltas: 100% (755115/755115), done. Checking out files: 100% (22584/22584), done.
然後去到htc-msm branch: cd kernel
git checkout -b htc-msm origin/htc-msm
屏幕信息:
Branch htc-msm set up to track remote branch refs/remotes/origin/htc-msm. Switched to a new branch "htc-msm"

下載ARM的toolchain, 大概64MB左右, 下到~/android-kernel: 下
載
:
http://www.codesourcery.com/gnu_toolchains/arm/portal/package2549/public/arm-none-linux-gnueabi/arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

cd ~/android-kernel
tar xjf arm-2008q1-126-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
編譯kernel

准備預設的Kaiser 配置文件.config
cd ~/android-kernel/kernel

make htckaiser_defconfig ARCH=arm
然後編譯zImage:
export PATH=~/android-kernel/arm-2008q1/bin:$PATH
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
編譯好的在: ~/android-kernel/kernel/arch/arm/boot/zImage

如果你的機器是多核的, 可以編譯的時候用-j <cores/cpus_number>來加速:
比如, 雙核的可以:
make -j 2 zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi
滿意請採納謝謝

G. intel fortran如何實現單機多核並行運算

請使用openmp。

打開OpenMP支持，方法如下：

選擇項目(Project) -> 屬性(property) -> Fortran -> 語言(Language),在 Process OpenMP Directives 選項中選擇 Generate Parallel Code (/Qopenmp),點擊確定以打開 OpenMP 支持。

示例代碼：

H. QT5靜態編譯無法載入資料庫插件

今天終於自己靜態編譯過了QT5.3.1, 成功用在項目上了, 記錄下configure指令.
configure -confirm-license -opensource -platform win32-msvc2013 -mp -debug-and-release -static -prefix "E:\Qt\5.3.1-static-vs2013" -qt-sql-sqlite -qt-zlib -qt-libpng -qt-libjpeg -opengl desktop -qt-freetype -no-qml-debug -no-angle -nomake tests -nomake examples -skip qtwebkit

其中 -mp 是啟用多核編譯的開關

I. python如何利用多核處理器

GIL 與 Python 線程的糾葛

GIL 是什麼東西？它對我們的 python 程序會產生什麼樣的影響？我們先來看一個問題。運行下面這段 python 程序，CPU 佔用率是多少？

# 請勿在工作中模仿，危險:)def dead_loop(): while True: passdead_loop()

答案是什麼呢，佔用 100％ CPU？那是單核！還得是沒有超線程的古董 CPU。在我的雙核 CPU 上，這個死循環只會吃掉我一個核的工作負荷，也就是只佔用 50％ CPU。那如何能讓它在雙核機器上佔用 100％ 的 CPU 呢？答案很容易想到，用兩個線程就行了，線程不正是並發分享 CPU 運算資源的嗎。可惜答案雖然對了，但做起來可沒那麼簡單。下面的程序在主線程之外又起了一個死循環的線程

import threadingdef dead_loop(): while True: pass# 新起一個死循環線程t = threading.Thread(target=dead_loop)t.start()# 主線程也進入死循環dead_loop()t.join()

按道理它應該能做到佔用兩個核的 CPU 資源，可是實際運行情況卻是沒有什麼改變，還是只佔了 50％ CPU 不到。這又是為什麼呢？難道 python 線程不是操作系統的原生線程？打開 system monitor 一探究竟，這個佔了 50% 的 python 進程確實是有兩個線程在跑。那這兩個死循環的線程為何不能占滿雙核 CPU 資源呢？其實幕後的黑手就是 GIL。

GIL 的迷思：痛並快樂著

GIL 的全稱為Global Interpreter Lock，意即全局解釋器鎖。在 Python 語言的主流實現 CPython 中，GIL 是一個貨真價實的全局線程鎖，在解釋器解釋執行任何 Python 代碼時，都需要先獲得這把鎖才行，在遇到 I/O 操作時會釋放這把鎖。如果是純計算的程序，沒有 I/O 操作，解釋器會每隔 100 次操作就釋放這把鎖，讓別的線程有機會執行（這個次數可以通過sys.setcheckinterval來調整）。所以雖然 CPython 的線程庫直接封裝操作系統的原生線程，但 CPython 進程做為一個整體，同一時間只會有一個獲得了 GIL 的線程在跑，其它的線程都處於等待狀態等著 GIL 的釋放。這也就解釋了我們上面的實驗結果：雖然有兩個死循環的線程，而且有兩個物理 CPU 內核，但因為 GIL 的限制，兩個線程只是做著分時切換，總的 CPU 佔用率還略低於 50％。

看起來 python 很不給力啊。GIL 直接導致 CPython 不能利用物理多核的性能加速運算。那為什麼會有這樣的設計呢？我猜想應該還是歷史遺留問題。多核 CPU 在 1990 年代還屬於類科幻，Guido van Rossum 在創造 python 的時候，也想不到他的語言有一天會被用到很可能 1000＋ 個核的 CPU 上面，一個全局鎖搞定多線程安全在那個時代應該是最簡單經濟的設計了。簡單而又能滿足需求，那就是合適的設計（對設計來說，應該只有合適與否，而沒有好與不好）。怪只怪硬體的發展實在太快了，摩爾定律給軟體業的紅利這么快就要到頭了。短短 20 年不到，代碼工人就不能指望僅僅靠升級 CPU 就能讓老軟體跑的更快了。在多核時代，編程的免費午餐沒有了。如果程序不能用並發擠干每個核的運算性能，那就意謂著會被淘汰。對軟體如此，對語言也是一樣。那 Python 的對策呢？

Python 的應對很簡單，以不變應萬變。在最新的 python 3 中依然有 GIL。之所以不去掉，原因嘛，不外以下幾點：

• 欲練神功，揮刀自宮：

  CPython 的 GIL 本意是用來保護所有全局的解釋器和環境狀態變數的。如果去掉 GIL，就需要多個更細粒度的鎖對解釋器的眾多全局狀態進行保護。或者採用 Lock-Free 演算法。無論哪一種，要做到多線程安全都會比單使用 GIL 一個鎖要難的多。而且改動的對象還是有 20 年歷史的 CPython 代碼樹，更不論有這么多第三方的擴展也在依賴 GIL。對 Python 社區來說，這不異於揮刀自宮，重新來過。

• 就算自宮，也未必成功：

  有位牛人曾經做了一個驗證用的 CPython，將 GIL 去掉，加入了更多的細粒度鎖。但是經過實際的測試，對單線程程序來說，這個版本有很大的性能下降，只有在利用的物理 CPU 超過一定數目後，才會比 GIL 版本的性能好。這也難怪。單線程本來就不需要什麼鎖。單就鎖管理本身來說，鎖 GIL 這個粗粒度的鎖肯定比管理眾多細粒度的鎖要快的多。而現在絕大部分的 python 程序都是單線程的。再者，從需求來說，使用 python 絕不是因為看中它的運算性能。就算能利用多核，它的性能也不可能和 C/C++ 比肩。費了大力氣把 GIL 拿掉，反而讓大部分的程序都變慢了，這不是南轅北轍嗎。

• 難道 Python 這么優秀的語言真的僅僅因為改動困難和意義不大就放棄多核時代了嗎？其實，不做改動最最重要的原因還在於：不用自宮，也一樣能成功！

其它神功

那除了切掉 GIL 外，果然還有方法讓 Python 在多核時代活的滋潤？讓我們回到本文最初的那個問題：如何能讓這個死循環的 Python 腳本在雙核機器上佔用 100％ 的 CPU？其實最簡單的答案應該是：運行兩個 python 死循環的程序！也就是說，用兩個分別占滿一個 CPU 內核的 python 進程來做到。確實，多進程也是利用多個 CPU 的好方法。只是進程間內存地址空間獨立，互相協同通信要比多線程麻煩很多。有感於此，Python 在 2.6 里新引入了multiprocessing這個多進程標准庫，讓多進程的 python 程序編寫簡化到類似多線程的程度，大大減輕了 GIL 帶來的不能利用多核的尷尬。

這還只是一個方法，如果不想用多進程這樣重量級的解決方案，還有個更徹底的方案，放棄 Python，改用 C/C++。當然，你也不用做的這么絕，只需要把關鍵部分用 C/C++ 寫成 Python 擴展，其它部分還是用 Python 來寫，讓 Python 的歸 Python，C 的歸 C。一般計算密集性的程序都會用 C 代碼編寫並通過擴展的方式集成到 Python 腳本里（如 NumPy 模塊）。在擴展里就完全可以用 C 創建原生線程，而且不用鎖 GIL，充分利用 CPU 的計算資源了。不過，寫 Python 擴展總是讓人覺得很復雜。好在 Python 還有另一種與 C 模塊進行互通的機制 : ctypes

利用 ctypes 繞過 GIL

ctypes 與 Python 擴展不同，它可以讓 Python 直接調用任意的 C 動態庫的導出函數。你所要做的只是用 ctypes 寫些 python 代碼即可。最酷的是，ctypes 會在調用 C 函數前釋放 GIL。所以，我們可以通過 ctypes 和 C 動態庫來讓 python 充分利用物理內核的計算能力。讓我們來實際驗證一下，這次我們用 C 寫一個死循環函數

• extern"C"{ void DeadLoop() { while (true); }}



用上面的 C 代碼編譯生成動態庫libdead_loop.so（Windows 上是dead_loop.dll）

，接著就要利用 ctypes 來在 python 里 load 這個動態庫，分別在主線程和新建線程里調用其中的DeadLoop

• from ctypes import *from threading import Threadlib = cdll.LoadLibrary("libdead_loop.so")t = Thread(target=lib.DeadLoop)t.start()lib.DeadLoop()



這回再看看 system monitor，Python 解釋器進程有兩個線程在跑，而且雙核 CPU 全被占滿了，ctypes 確實很給力！需要提醒的是，GIL 是被 ctypes 在調用 C 函數前釋放的。但是 Python 解釋器還是會在執行任意一段 Python 代碼時鎖 GIL 的。如果你使用 Python 的代碼做為 C 函數的 callback，那麼只要 Python 的 callback 方法被執行時，GIL 還是會跳出來的。比如下面的例子：

• extern"C"{ typedef void Callback(); void Call(Callback* callback) { callback(); }}


• from ctypes import *from threading import Threaddef dead_loop(): while True: passlib = cdll.LoadLibrary("libcall.so")Callback = CFUNCTYPE(None)callback = Callback(dead_loop)t = Thread(target=lib.Call, args=(callback,))t.start()lib.Call(callback)



注意這里與上個例子的不同之處，這次的死循環是發生在 Python 代碼里 (DeadLoop函數) 而 C 代碼只是負責去調用這個 callback 而已。運行這個例子，你會發現 CPU 佔用率還是只有 50％ 不到。GIL 又起作用了。

其實，從上面的例子，我們還能看出 ctypes 的一個應用，那就是用 Python 寫自動化測試用例，通過 ctypes 直接調用 C 模塊的介面來對這個模塊進行黑盒測試，哪怕是有關該模塊 C 介面的多線程安全方面的測試，ctypes 也一樣能做到。

結語

雖然 CPython 的線程庫封裝了操作系統的原生線程，但卻因為 GIL 的存在導致多線程不能利用多個 CPU 內核的計算能力。好在現在 Python 有了易經筋（multiprocessing）, 吸星大法（C 語言擴展機制）和獨孤九劍（ctypes），足以應付多核時代的挑戰，GIL 切還是不切已經不重要了，不是嗎。