Linux下头文件以及库 编译链接运行时的搜寻路径顺序
Linux下头文件以及库 编译链接运行时的搜寻路径顺序 - ltshan139的专栏
LIBRARY_PATH 环境变量用于在程序编译期间查找动态链接库时指定查找共享库的路径，例如，指定gcc编译需要用到的动态链接库的目录。
LD_LIBRARY_PATH 环境变量用于在程序加载运行期间查找动态链接库时指定除了系统默认路径之外的其他路径，注意，LD_LIBRARY_PATH中指定的路径会在系统默认路径之前进行查找。
gcc 编译时头文件.h的搜寻路径
其搜寻优先顺序由高到低为：
1）先从 -I（大写i）指定的头文件目录开始找
2）然后从gcc环境变量 C_INCLUDE_PATH ，cplus_Include_path , OBJC_Include_Path指定的路径来寻找
3）最后从系统目录 /usr/include 或 /usr/local/include 或/usr/lib/gcc_lib/i386-linux/2.952/include 下寻找
4) 补充：从当前目录来搜寻 ./
ld 链接时动态库.so或静态库.a的搜寻路径
其优先顺序：
1）先从 -L 指定的目录来搜寻库
2）然后从gcc环境变量 LIBRARY_PATH指定的目录寻找
3）最后从系统目录 /lib 或 /usr/lib 或 /usr/local/lib来寻找
运行时动态库.so的加载路径
注意，只有动态库so文件才需要考虑运行时的加载。 动态库经常因为路径的原因导致无法加载的错误，这使得动态库使用起来相对比较麻烦些，但是它的优势也很明显：编译时不需要真正链接到可执行文件里面。这样意味着，每次动态库升级，不需要重新编译可执行文件，只需要把升级后的so文件拷贝到正确的加载路径即可。
其加载优先顺序为：
1）-L指定的动态库搜寻路径（通常不好使。 毕竟嵌入式环境中，编译和运行平台完全不一样）
2）环境变量LD_LIBRARY_PATH指定的动态库搜寻路径
3）/etc/ld.so.conf 里面添加动态库搜索路径，记得要执行ldconfig来生效。
4）默认系统运行库搜索路径 /lib 或 /usr/lib
————————————————
版权声明：本文为CSDN博主「ltshan139」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/avideointerfaces/article/details/96157710
链接的时候如何去掉没有用到的函数、目标文件
以前了解过ld在链接的时候，是以目标文件(.o)为单位的，所以libc里的源文件基本上都很短，甚至只定义一个函数。
为的是在链接的时候，不要把没有用到的函数也链进去，从而减小可执行文件或者动态库的大小。
(1) 但是如果你将很多函数都定义在一个源文件中了，又想要减size，怎么办呢？
Stack overflow上有一篇文章 C/C++ gcc & ld - remove unused symbols （ http://stackoverflow.com/questions/6687630/c-c-gcc-ld-remove-unused-symbols）
有讨论这个问题，里面提到的解决办法是:
编译每个源文件时加上编译选项 (2) 我写这篇文章的起因其实不是为了去除某个目标文件中没有用到的函数，而是想在链接时去除掉没有用到的目标文件。 解决办法很简单，只把需要的目标文件链接进去就可以了，这样size就能减小了。 EXCLUDES := $(shell cat ./exclude.txt) # put all files you want to exclude into this file OBJS := $(patsubst src/%.cpp,obj/%.o,$(NEWCPPFILES)) 办法很简单，但我觉得这个和我的理解有点不一样，所以就google了一下。 The linker drops unused object files only if they originate from a library. Object files explicitly passed to the linker are always linked into the program. 顺便说一下，这个blog里的关于linker的一系列文章写的很棒。-fdata-sections -ffunction-sections， 链接时加上选项-Wl,--gc-sections
这个例子就能很好地验证上述方法：
#include
void deadcode() { printf("This is d dead codez\n"); }
int main(void) { printf("This is main\n"); return 0 ; }
gcc -Os test.c -o test.elf
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections -Wl,--strip-all
比较一下test.elf的大小吧。
背景是我在实现某个feature时，一开始用了一种方法，后来又用了另一种方法，两种方法都有几个源文件。第一种方法由于某种原因生成的目标文件很大，而第二种方法则可以大幅减小size。
在写Makefile的时候呢，由于项目比较小，没有精确地去控制链接哪些文件，所以导致一股脑地把源文件都编译了，把目标文件都加到链接命令里了。
结果当然是可执行文件的大小没有减下去了。
#---------------------------------------------------------------------------------
#OBJS := $(patsubst src/%.cpp,obj/%.o,$(wildcard src/.cpp))
#OBJS += $(patsubst src/%.c,obj/%.o,$(wildcard src/.c))
CPPFILES := $(shell find src/ -name '.cpp')
NEWCPPFILES := $(filter-out $(EXCLUDES), $(CPPFILES))
CFILES := $(shell find src/ -name '.c')
NEWCFILES := $(filter-out $(EXCLUDES), $(CFILES))
OBJS += $(patsubst src/%.c,obj/%.o,$(NEWCFILES))
#---------------------------------------------------------------------------------
(debug makefile:
在这篇文章中有一些解释： http://blog.copton.net/articles/linker/#linker-dependencies
————————————————
版权声明：本文为CSDN博主「hp_truth」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/hp_truth/article/details/40186665