gcc编译选项

一. ar编译指令
将编译好的.o文件，合并成一个.a静态库
二. 编译选项
1.-I（大写的i）：头文件目录
2.-L（大写的l）：库路径。比方说指定了某个路径为库的路径，则编译时第一时间会在该路径下寻找库，寻找的路径顺序为：指定路径–>/lib–>/usr/lib–>/usr/local/lib
3.-l（小写的l）：指定程序要链接的库
常用的编译选项：
（1）-lm：链接m动态库，即math数学库
（2）-static –lm：链接m静态库
（3）-ldl：当代码中用到dlopen，dlsym，dlclose，dlerror显示加载动态库时，需加上
（4）-lstdc++：加上该编译选项表示编译c++文件，链接c++库
（5）-lc：表示编译c文件，链接c库，gcc默认编译c文件和链接c库，当编译c文件时可以不用额外加该选项
（6）-lpthread：链接到pthread的库（1、-lpthread是较为老式的解决方法，pthread新加了对于宏D_REENTRANT的定义，-pthread会被展开为“-D_REENTRANT -lpthread”，它不仅可以链接pthread库，还可以打开系统头文件中的各种多线程支持分支，比如，我们常常使用的错误码标志errno，如果没有定义_REENTRANT，则实现为一个全局变量；若是定义了_REENTRANT，则会实现为每线程独有，从而避免线程竞争错误。
4.-shared：编译so动态库时需要加上
-fPIC：用于生成so库。-fPIC 作用于编译阶段，告诉编译器产生与位置无关代码(Position-Independent Code)，则产生的代码中，没有绝对地址，全部使用相对地址，故而代码可以被加载器加载到内存的任意位置，都可以正确的执行。这正是共享库所要求的，共享库被加载时，在内存的位置不是固定的。（如果不加-fPIC,则加载.so文件的代码段时,代码段引用的数据对象需要重定位, 重定位会修改代码段的内容,这就造成每个使用这个.so文件代码段的进程在内核里都会生成这个.so文件代码段的copy.每个copy都不一样,取决于这个.so文件代码段和数据段内存映射的位置. 也就是不加fPIC编译出来的so,是要再加载时根据加载到的位置再次重定位的.(因为它里面的代码并不是位置无关代码) 如果被多个应用程序共同使用,那么它们必须每个程序维护一份.so的代码副本了.(因为.so被每个程序加载的位置都不同,显然这些重定位后的代码也不同,当然不能共享) ）
5.-pthread可移植性较强：在Linux中，pthread是作为一个单独的库存在的（libpthread.so），但是在其他Unix变种中却不一定，比如在FreeBSD中是没有单独的pthread库的，因此在FreeBSD中不能使用-lpthread来链接pthread，而使用-pthread则不会存在这个问题，因为FreeBSD的编译器能正确将-pthread展开为该系统下的依赖参数。同样道理，其他不同的变种也会有这样那样的区别，如果使用-lpthread，则可能在移植到其他Unix变种中时会出现问题，为了保持较高的可移植性，我们最好还是使用-pthread（尽管这种做法未被接纳成为C标准，但已基本是事实标准）。）
6.-Wall：打开所有编译警告
7.-Werror：要求gcc将所有的警告当成错误进行处理
8.-Wno-unused-function：发现不使用的函数不警告
9.-D：添加宏定义
10.-g：生成的执行文件运行出现问题时，可支持使用gdb定位。加上该编译选项后，（1）创建符号表（2）关闭所有的优化机制，程序执行过程中严格按照c代码来执行
11.-mcpu=cortex-a53：选择处理器（https://blog.csdn.net/u014470361/article/details/87931856）
-mfloat-abi=softfp：软浮点
-mfpu=neon-vfpv4：指定为NEON+VFP结构
-fno-aggressive-loop-optimizations：避免循环变量的一些激进的优化
-fno-unaligned-access：非对齐访问编译器选项（默认arm都是aligend-access，然而如果代码里有使用__attribute__((packed))等参数定义结构体时，会出现结构体成员是pack的也就是非对齐的，此时如果没有使能允许非对齐访问（对结构体成员赋值等操作）会导致abort。）
-ffunction-section –fdata-sections
（https://www.cnblogs.com/dylancao/archive/2004/01/13/9481160.html）