常见的编译选项中

⑴ 如何设置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