编译链接的套路有哪些?
不知道大家平时编程过程中使用动态链接库的情况多不多，如果一个程序引用了无数个动态链接库，那就有可能引入符号冲突的问题，问题如下：
想象中
实际上
下面，我们尝试解决它。
最开始介绍下g++基本命令参数：
g++-c 编译源文件，但是不进行链接-o 指定输出文件的名字-s strip，移除符号信息-l 指令搜索链接库的路径-l 指定要链接的链接库-shared 产生动态目标文件
先来看一段代码：
#include void dothing() { printf(work ); }
再定义一个简单的main.cc程序：
#include void dothing(); int main() { printf(start ); dothing(); printf(finished ); return 0;}
编译这两个文件，并分别打包成静态库：
g++ -c work.cc -o work.oar rc libwork.a work.og++ -c main.cc -o main.oar rc libmain.a main.o
现在将这两个静态库链接成一个可执行文件，注意链接器如果发现当前库中使用了没有被定义的符号，它只会向后查找，因此最低级别没有其它依赖的库应该放在最右边，如果出现了符号冲突问题，链接器会使用最左边的符号。
如果这样进行链接：
$ g++ -s -l. -o main.exe -lwork -lmain./libmain.a(main.o): in function `main':main.cc undefined reference to `dothing()'collect2: error: ld returned 1 exit status
链接失败，因为main库里的dothing符号没有被定义，链接器向后查找，没有找到对应的符号定义，这里更改下链接库的顺序：
g++ -s -l. -o main.exe -lmain -lwork$ ./main.exestartworkfinished
链接成功。
现在写一个简单的容易产生符号冲突的文件conflict.cc：
#include void dothing() { printf(conflict ); }
编译并打包成静态库：
g++ -c conflict.cc -o conflict.oar rc libconflict.a conflict.o
如果按这样的顺序链接成一个可执行程序：
$ g++ -s -l. -o main.exe -lmain -lwork -lconflict$ ./main.exestartworkfinished
如果稍微更改一下链接的顺序：
$ g++ -s -l. -o main.exe -lmain -lconflict -lwork$ ./main.exestartconflictfinished
这里发现顺序的不同导致了程序输出内容不同，究其原因就是那潜在的符号冲突。
现在再试试动态库，先介绍如何使用动态库：
$ rm libconflict.a$ g++ -shared conflict.o -o libconflict.so$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartconflictfinished
现在再引用一个中间层在动态链接库中调用conflict的文件layer.cc
#include void dothing();void dolayer() { printf(layer ); dothing();}
并把layer和conflict打包成一个动态链接库：
$ g++ -c layer.cc -o layer.o$ g++ -shared layer.o conflict.o -o libconflict.so
然后更新main.c程序，main里面调用layer，layer里调用conflict：
#include void dolayer();int main() { printf(start ); dolayer(); printf(finished ); return 0;}
编译链接执行：
$ g++ -c main.cc -o main.o$ ar rc libmain.a main.o$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartlayerconflictfinished
正常输出，没啥问题，现在再把之前的work.cc也塞到main.cc中，观察下冲突：
#include void dothing();void dolayer();int main() { printf(start ); dothing(); dolayer(); printf(finished ); return 0;}
把work.o和main.o打包成一个库，之后和conflict链接成一个可执行程序，运行：
$ g++ -c main.cc -o main.o$ ar rc libmain.a main.o work.o$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartworklayerworkfinished
这里输出了两个work，正常情况下第二个work应该输出conflict，怎么解决呢？
可以考虑使用-fvisibility=hidden来隐藏内部的符号，链接库内部使用的符号把它隐藏掉，不让它被导出，外部也不会改变它的调用路径。
先使用nm看一下libconflict.so里面的符号：
$ nm -cd libconflict.so w _itm_deregistertmclonetable w _itm_registertmclonetable000000000000065a t dolayer()0000000000000672 t dothing()0000000000201030 b __bss_start w __cxa_finalize w __gmon_start__0000000000201030 d _edata0000000000201038 b _end0000000000000688 t _fini0000000000000528 t _init u puts
如果把符号隐藏掉：
$ g++ -fvisibility=hidden -c layer.cc -o layer.o$ g++ -fvisibility=hidden -c conflict.cc -o conflict.o$ g++ -shared layer.o conflict.o -o libconflict.so再使用nm看一下libconflict.so里面的符号：$ nm -cd libconflict.so w _itm_deregistertmclonetable w _itm_registertmclonetable0000000000201028 b __bss_start w __cxa_finalize w __gmon_start__0000000000201028 d _edata0000000000201030 b _end0000000000000618 t _fini00000000000004c0 t _init u puts
这样的话main函数肯定不能调用dolayer啦，因为dolayer符号没有暴露出来：
$ g++ -s -l. -o main.exe -lmain -lconflict./libmain.a(main.o): in function `main':main.cc undefined reference to `dolayer()'collect2: error: ld returned 1 exit statu
那怎么暴露出来特定符号呢，直接看代码，改动了layer.cc：
#include void dothing();__attribute__ ((visibility (default))) void dolayer() { printf(layer ); dothing();}
再编译链接运行看看结果：
$ g++ -fvisibility=hidden -c layer.cxx -o layer.o$ g++ -shared layer.o conflict.o -o libconflict.so$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartworklayerconflictfinished
发现已经是我们期待的结果啦，符号冲突的问题因此被解决。
是不是感觉很麻烦，难道每个要暴露的符号都要加上__attribute__这种修饰吗，这里其实可以写一个export文件，告诉编译器要导出的所有符号有哪些。
export.txt { global: *dolayer*; local: *;};g++ -wl,--version-script=export.txt -s -shared layer.o conflict.o -o libconflict.so
但这种方式只有在gcc中才可以被使用，我在clang中尝试使用但是失败啦，所以为了兼容性不建议使用这种方式，还是消停的使用__attribute__来解决符号冲突问题吧。
tips
通过隐藏符号可以减小可执行程序的大小，还可以解决符号冲突问题，但有个缺点，因为隐藏了符号，线上程序运行时如果出现crash，通过堆栈信息我们看不到具体函数调用路径，给定位问题带来了困难。所以，是否需要使用这种办法，还应根据实际情况具体抉择。
原文标题：原来编译链接还有这么多套路……
文章出处：【微信公众号：嵌入式arm】欢迎添加关注！文章转载请注明出处。
AA-1800DL原子吸收光谱仪测定茶水中重金属的含量及其浸出实验因素分析的应用方案
杭州市将建C2C电子商务创业园
统信软件与厂商合作协助构建安全可信的基础软件底座
在全球人口老龄化危机的背景下 人工智能发挥的作用越来越大
英伟达财报即将揭晓 机构展望普遍乐观Q3收入或增1.7倍
编译链接的套路有哪些?
用雷达给道路做“B超”
Cypress推出新型软件工具CyClockWizard
意法半导体LED电视 200W数字电源解决方案满足严格的生态设计标准
倾斜传感器的三种类型说明
希尔顿酒店使用智能访客机系统提升用户体验
5G到来，英特尔、高通等5家芯片制造商将获益最多
既能悬浮点灯又能悬浮充电的手表
结构体基本用法详解
回顾FPGA的三个时代分析和可编程介绍的分析
升级机型覆盖面超乎想象，MIUI8.2稳定版五大升级亮点
高增益LC谐振放大器的设计
IGBT 的结构及主要参数
使用基于Eclipse开发Android应用程序的好处
用CPLD支持多个SD器件
想象中
实际上
下面，我们尝试解决它。
最开始介绍下g++基本命令参数：
g++-c 编译源文件，但是不进行链接-o 指定输出文件的名字-s strip，移除符号信息-l 指令搜索链接库的路径-l 指定要链接的链接库-shared 产生动态目标文件
先来看一段代码：
#include void dothing() { printf(work ); }
再定义一个简单的main.cc程序：
#include void dothing(); int main() { printf(start ); dothing(); printf(finished ); return 0;}
编译这两个文件，并分别打包成静态库：
g++ -c work.cc -o work.oar rc libwork.a work.og++ -c main.cc -o main.oar rc libmain.a main.o
现在将这两个静态库链接成一个可执行文件，注意链接器如果发现当前库中使用了没有被定义的符号，它只会向后查找，因此最低级别没有其它依赖的库应该放在最右边，如果出现了符号冲突问题，链接器会使用最左边的符号。
如果这样进行链接：
$ g++ -s -l. -o main.exe -lwork -lmain./libmain.a(main.o): in function `main':main.cc undefined reference to `dothing()'collect2: error: ld returned 1 exit status
链接失败，因为main库里的dothing符号没有被定义，链接器向后查找，没有找到对应的符号定义，这里更改下链接库的顺序：
g++ -s -l. -o main.exe -lmain -lwork$ ./main.exestartworkfinished
链接成功。
现在写一个简单的容易产生符号冲突的文件conflict.cc：
#include void dothing() { printf(conflict ); }
编译并打包成静态库：
g++ -c conflict.cc -o conflict.oar rc libconflict.a conflict.o
如果按这样的顺序链接成一个可执行程序：
$ g++ -s -l. -o main.exe -lmain -lwork -lconflict$ ./main.exestartworkfinished
如果稍微更改一下链接的顺序：
$ g++ -s -l. -o main.exe -lmain -lconflict -lwork$ ./main.exestartconflictfinished
这里发现顺序的不同导致了程序输出内容不同，究其原因就是那潜在的符号冲突。
现在再试试动态库，先介绍如何使用动态库：
$ rm libconflict.a$ g++ -shared conflict.o -o libconflict.so$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartconflictfinished
现在再引用一个中间层在动态链接库中调用conflict的文件layer.cc
#include void dothing();void dolayer() { printf(layer ); dothing();}
并把layer和conflict打包成一个动态链接库：
$ g++ -c layer.cc -o layer.o$ g++ -shared layer.o conflict.o -o libconflict.so
然后更新main.c程序，main里面调用layer，layer里调用conflict：
#include void dolayer();int main() { printf(start ); dolayer(); printf(finished ); return 0;}
编译链接执行：
$ g++ -c main.cc -o main.o$ ar rc libmain.a main.o$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartlayerconflictfinished
正常输出，没啥问题，现在再把之前的work.cc也塞到main.cc中，观察下冲突：
#include void dothing();void dolayer();int main() { printf(start ); dothing(); dolayer(); printf(finished ); return 0;}
把work.o和main.o打包成一个库，之后和conflict链接成一个可执行程序，运行：
$ g++ -c main.cc -o main.o$ ar rc libmain.a main.o work.o$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartworklayerworkfinished
这里输出了两个work，正常情况下第二个work应该输出conflict，怎么解决呢？
可以考虑使用-fvisibility=hidden来隐藏内部的符号，链接库内部使用的符号把它隐藏掉，不让它被导出，外部也不会改变它的调用路径。
先使用nm看一下libconflict.so里面的符号：
$ nm -cd libconflict.so w _itm_deregistertmclonetable w _itm_registertmclonetable000000000000065a t dolayer()0000000000000672 t dothing()0000000000201030 b __bss_start w __cxa_finalize w __gmon_start__0000000000201030 d _edata0000000000201038 b _end0000000000000688 t _fini0000000000000528 t _init u puts
如果把符号隐藏掉：
$ g++ -fvisibility=hidden -c layer.cc -o layer.o$ g++ -fvisibility=hidden -c conflict.cc -o conflict.o$ g++ -shared layer.o conflict.o -o libconflict.so再使用nm看一下libconflict.so里面的符号：$ nm -cd libconflict.so w _itm_deregistertmclonetable w _itm_registertmclonetable0000000000201028 b __bss_start w __cxa_finalize w __gmon_start__0000000000201028 d _edata0000000000201030 b _end0000000000000618 t _fini00000000000004c0 t _init u puts
这样的话main函数肯定不能调用dolayer啦，因为dolayer符号没有暴露出来：
$ g++ -s -l. -o main.exe -lmain -lconflict./libmain.a(main.o): in function `main':main.cc undefined reference to `dolayer()'collect2: error: ld returned 1 exit statu
那怎么暴露出来特定符号呢，直接看代码，改动了layer.cc：
#include void dothing();__attribute__ ((visibility (default))) void dolayer() { printf(layer ); dothing();}
再编译链接运行看看结果：
$ g++ -fvisibility=hidden -c layer.cxx -o layer.o$ g++ -shared layer.o conflict.o -o libconflict.so$ g++ -s -l. -o main.exe -lmain -lconflict$ ld_library_path=. ./main.exestartworklayerconflictfinished
发现已经是我们期待的结果啦，符号冲突的问题因此被解决。
是不是感觉很麻烦，难道每个要暴露的符号都要加上__attribute__这种修饰吗，这里其实可以写一个export文件，告诉编译器要导出的所有符号有哪些。
export.txt { global: *dolayer*; local: *;};g++ -wl,--version-script=export.txt -s -shared layer.o conflict.o -o libconflict.so
但这种方式只有在gcc中才可以被使用，我在clang中尝试使用但是失败啦，所以为了兼容性不建议使用这种方式，还是消停的使用__attribute__来解决符号冲突问题吧。
tips
通过隐藏符号可以减小可执行程序的大小，还可以解决符号冲突问题，但有个缺点，因为隐藏了符号，线上程序运行时如果出现crash，通过堆栈信息我们看不到具体函数调用路径，给定位问题带来了困难。所以，是否需要使用这种办法，还应根据实际情况具体抉择。
原文标题：原来编译链接还有这么多套路……
文章出处：【微信公众号：嵌入式arm】欢迎添加关注！文章转载请注明出处。
AA-1800DL原子吸收光谱仪测定茶水中重金属的含量及其浸出实验因素分析的应用方案
杭州市将建C2C电子商务创业园
统信软件与厂商合作协助构建安全可信的基础软件底座
在全球人口老龄化危机的背景下 人工智能发挥的作用越来越大
英伟达财报即将揭晓 机构展望普遍乐观Q3收入或增1.7倍
编译链接的套路有哪些?
用雷达给道路做“B超”
Cypress推出新型软件工具CyClockWizard
意法半导体LED电视 200W数字电源解决方案满足严格的生态设计标准
倾斜传感器的三种类型说明
希尔顿酒店使用智能访客机系统提升用户体验
5G到来，英特尔、高通等5家芯片制造商将获益最多
既能悬浮点灯又能悬浮充电的手表
结构体基本用法详解
回顾FPGA的三个时代分析和可编程介绍的分析
升级机型覆盖面超乎想象，MIUI8.2稳定版五大升级亮点
高增益LC谐振放大器的设计
IGBT 的结构及主要参数
使用基于Eclipse开发Android应用程序的好处
用CPLD支持多个SD器件