常見的編譯選項中

⑴ 如何設置NDK的編譯選項

1. 概述
首先回顧一下 Android NDK 開發中，Android.mk 和 Application.mk 各自的職責。
Android.mk，負責配置如下內容：
（1） 模塊名（LOCAL_MODULE）
（2） 需要編譯的源文件（LOCAL_SRC_FILES）
（3） 依賴的第三方庫（LOCAL_STATIC_LIBRARIES，LOCAL_SHARED_LIBRARIES）
（4） 編譯/鏈接選項（LOCAL_LDLIBS、LOCAL_CFLAGS）
Application.mk，負責配置如下內容：
（1） 目標平台的ABI類型（默認值：armeabi）（APP_ABI）
（2） Toolchains（默認值：GCC 4.8）
（3） C++標准庫類型（默認值：system）（APP_STL）
（4） release/debug模式（默認值：release）
由此我們可以看到，本文所涉及的編譯選項在Android.mk和Application.mk中均有出現，下面我們將一個個詳細介紹。
2. APP_ABI
ABI全稱是：Application binary interface，即：應用程序二進制介面，它定義了一套規則，允許編譯好的二進制目標代碼在所有兼容該ABI的操作系統和硬體平台中無需改動就能運行。（具體的定義請參考 網路 或者 維基網路 ）
由上述定義可以判斷，ABI定義了規則，而具體的實現則是由編譯器、CPU、操作系統共同來完成的。不同的CPU晶元（如：ARM、Intel x86、MIPS）支持不同的ABI架構，常見的ABI類型包括：armeabi，armeabi-v7a，x86，x86_64，mips，mips64，arm64-v8a等。
這就是為什麼我們編譯出來的可以運行於Windows的二進製程序不能運行於Mac OS/linux/Android平台了，因為CPU晶元和操作系統均不相同，支持的ABI類型也不一樣，因此無法識別對方的二進製程序。
而我們所說的「交叉編譯」的核心原理也跟這些密切相關，交叉編譯，就是使用交叉編譯工具，在一個平台上編譯生成另一個平台上的二進制可執行程序，為什麼可以做到？因為交叉編譯工具實現了另一個平台所定義的ABI規則。我們在Windows/Linux平台使用Android NDK交叉編譯工具來編譯出Android平台的庫也是這個道理。
這里給出最新 Android NDK 所支持的ABI類型及區別：

那麼，如何指定ABI類型呢？在 Application.mk 文件中添加一行即可：
APP_ABI := armeabi-v7a //只編譯armeabi-v7a版本APP_ABI := armeabi armeabi-v7a //同時編譯armeabi，armeabi-v7a版本APP_ABI := all //編譯所有版本
3. LOCAL_LDLIBS
Android NDK 除了提供了Bionic libc庫，還提供了一些其他的庫，可以在 Android.mk 文件中通過如下方式添加依賴：
LOCAL_LDLIBS := -lfoo
其中，如下幾個庫在 Android NDK 編譯時就默認鏈接了，不需要額外添加在 LOCAL_LDLIBS 中：
（1） Bionic libc庫
（2） pthread庫（-lpthread）
（3） math（-lmath）
（4） C++ support library (-lstdc++)
下面我列了一個表，給出了可以添加到「LOCAL_LDLIBS」中的不同版本的Android NDK所支持的庫：

下面是我總結的一些常用的CFLAGS編譯選項：
（1）通用的編譯選項
-O2 編譯優化選項，一般選擇O2，兼顧了優化程度與目標大小
-Wall 打開所有編譯過程中的Warning
-fPIC 編譯位置無關的代碼，一般用於編譯動態庫
-shared 編譯動態庫
-fopenmp 打開多核並行計算，
-Idir 配置頭文件搜索路徑，如果有多個-I選項，則路徑的搜索先後順序是從左到右的，即在前面的路徑會被選搜索
-nostdinc 該選項指示不要標准路徑下的搜索頭文件，而只搜索-I選項指定的路徑和當前路徑。
--sysroot=dir 用dir作為頭文件和庫文件的邏輯根目錄，例如，正常情況下，如果編譯器在/usr/include搜索頭文件，在/usr/lib下搜索庫文件，它將用dir/usr/include和dir/usr/lib替代原來的相應路徑。
-llibrary 查找名為library的庫進行鏈接
-Ldir 增加-l選項指定的庫文件的搜索路徑，即編譯器會到dir路徑下搜索-l指定的庫文件。
-nostdlib 該選項指示鏈接的時候不要使用標准路徑下的庫文件
（2） ARM平台相關的編譯選項
-marm -mthumb 二選一，指定編譯thumb指令集還是arm指令集
-march=name 指定特定的ARM架構，常用的包括：-march=armv6， -march=armv7-a
-mfpu=name 給出目標平台的浮點運算處理器類型，常用的包括：-mfpu=neon，-mfpu=vfpv3-d16
-mfloat-abi=name 給出目標平台的浮點預算ABI，支持的參數包括：「soft」, 「softfp」 and 「hard」

⑵ linux中常用編譯器是什麼

Linux 下可用的編譯器有 GCC、EGCS 和 PGCC，其中最常用的編譯器便是 GCC。

GCC 起初是 GNU 推出的 C語言編
譯器，用於類 Unix 系統下的編程，所以名為 GNU C Compiler 。隨著眾多自由開發者的加入，GCC
發展迅速，如今已成為一個支持眾多語言的編譯器了，其中包括 C、C++、Ada、Object C 和 Java 等，以至於 GCC 開始被擴展為
GNU Compiler Collection ，也就是「GNU 編譯器集合」的意思。

GCC用法：

1、GCC基本用法及其選項

gcc 或 g++ 的用法跟參數含義幾乎一樣，他們最基本的用法是：

2、只編譯子程序（-c）

3、產生目標文件（-o）

4、附加調試信息（-g）

5、多文件編譯

6、連接庫文件。

⑶ Linux的終端怎麼運行C語言

不知道你是如何編譯的，如果沒有指定生成的文件名的話，那麼系統會默認的將可執行文件命名為a.out，執行的話先進入到可執行文件所在的目錄，然後 ./a.out 就可以了。如果你通過 - o 選項命名（假如名為test），那麼直接 ./test 即可執行。

⑷ centos 配置編譯選項是什麼

./configure ，這一步一般用來生成 Makefile，為下一步的編譯做准備，你可以通過在 configure 後加上參數來對安裝進行控制，比如
代碼:
./configure --prefix=/usr
上面的意思是將該軟體安裝在 /usr 下面，執行文件就會安裝在 /usr/bin （而不是默認的 /usr/local/bin),
資源文件就會安裝在 /usr/share（而不是默認的/usr/local/share）。
同時一些軟體的配置文件你可以通過指定 --sys-config= 參數進行設定。
有一些軟體還可以加上 --with、--enable、--without、--disable 等等參數對編譯加以控制，
你可以通過允許 ./configure --help 察看詳細的說明幫助。

⑸ gcc的常用編譯命令

gcc編譯命令總結：
1.無選項
gcc test.c
默認生成可執行文件a.out
2.-o 生成的可執行文件名
gcc test.c -o test
3.多個文件一起編譯
gcc test1.c test2.c -o test
4.-O選項
gcc -O1 test1.c -o test
作用:使用編譯優化級別1編譯程序，優化級別為1-3，級別越大優化效果越好，但編譯時間越長
5 -g選項 ：生成可調試信息
6.鏈接庫的命令
gcc test.c -lm -o test
-lm 表示鏈接系統的數學庫 libm.a

⑹ 求助：GCC編譯選項加上

Debug選項:
在 gcc編譯源代碼時指定-g選項可以產生帶有調試信息的目標代碼,gcc可以為多個不同平台上帝不同調試器提供調試信息,默認gcc產生的調試信息是為 gdb使用的,可以使用-gformat 指定要生成的調試信息的格式以提供給其他平台的其他調試器使用.常用的格式有
-ggdb:生成gdb專 用的調試信息,使用最適合的格式(DWARF 2,stabs等)會有一些gdb專用的擴展,可能造成其他調試器無法運行.
-gstabs:使用 stabs格式,不包含gdb擴展,stabs常用於BSD系統的DBX調試器.
-gcoff:產生COFF格式的調試信息,常用於System V下的SDB調試器;
-gxcoff:產生XCOFF格式的調試信息,用於IBM的RS/6000下的DBX調試器;
-gdwarf- 2:產生DWARF version2 的格式的調試信息,常用於IRIXX6上的DBX調試器.GCC會使用DWARF version3的一些特性.
可 以指定調試信息的等級:在指定的調試格式後面加上等級:
如: -ggdb2 等,0代表不產生調試信息.在使用-gdwarf-2時因為最早的格式為-gdwarf2會造成混亂,所以要額外使用一個-glevel來指定調試信息的 等級,其他格式選項也可以另外指定等級.
gcc可以使用-p選項指定生成信息以供porf使用.

⑺ Android 編譯選項user，userdebug和eng的區別

要了解Android編譯選項eng、user和userdebug的區別，需先了解下LOCAL_MODULE_TAGS這一Android.mk文件里的配置項，一般配置形式為LOCAL_MODULE_TAGS := user eng optional test這個樣子。
那麼LOCAL_MODULE_TAGS設置為不同值有何作用呢？下面是對應不同值編譯的結果：
1、user：只有在user版本時該模塊才被編譯進去；
2、eng：只有在eng版本時該模塊才被編譯進去；
3、test：只有在tests版本時該模塊才被編譯進去；
4、optional：在所有版本中都編譯該模塊進去。

其中的值可設置為1個或多個，分別對應編譯選項的同一個或多個。那麼eng、user、userdebug的區別是什麼呢？接下來一一揭開：
1、當make eng時，也即相當於make。此時BuildType為eng，那麼其編譯進去的內容包括：
· Intended for platform-level debugging
· Installs moles tagged with: eng, debug, user, and/or development
· Installs non-APK moles that have no tags specified
· Installs APKs according to the proct definition files, in addition to tagged APKs
· Sets ro.secure=1
· Sets ro.debuggable=0
· Sets ro.kernel.android.checkjni=1
· adbd is enabled by default
2、當make user時，此時BuildType為user,那麼其編譯進去的內容包括：
· Intended to be the final release
· Installs moles tagged as user
· Installs non-APK moles that have no tags specified
· Installs APKs according to the proct definition files (tags are ignored for APK moles)
· Sets ro.secure=1
· Sets ro.debuggable=0
· adbd is disabled by default
3、當make userdebug時，此時BuildType為userdebug,那麼其編譯進去的內容包括：
the same as user, except:
· Intended for limited debugging
· Installs moles tagged with debug
· Sets ro.debuggable=1
· adbd is enabled by default