在嵌入式项目的开发过程中，只要工程里用到的预编译库稍微多起来，路径设置混乱、不同版本互相覆盖、同一个符号被重复定义这类问题就会变得非常常见，单靠把所有能看到的库文件一股脑儿塞进工程里并不能解决问题。更稳当的处理办法，是先花些力气把每一个库的来源、它所对应的芯片平台、当初编译时用了哪些选项，还有链接过程中各个库的先后次序都理清楚，然后再借助map文件和链接日志，准确地找出到底是哪两个目标文件或者哪两个库之间发生了冲突。

　　一、库文件的组织方式怎样才能更稳妥

　　管理这些库文件，最重要的一个原则就是要让每一个库都能被追溯回去，也就是说，任意拿一个库文件，都应该能清楚地说明它来自哪个功能模块、具体是什么版本、用哪一款编译器生成，以及编译的时候选了哪些参数。

　　1、按照硬件平台和功能模块分开存放目录

　　比较推荐的做法，是先按照芯片所处的平台、编译器的版本、构建的类型以及功能模块，来分别建好目录，例如可以把目录起名为cpu_core、driver、middleware、app_common、third_party这样一眼就能看明白的名字。需要特别留意的是，调试版本和发布版本对应的库文件不要混在一起放，单核运行的目标文件和多核运行的也不能共用同一个文件夹，否则很容易在链接阶段把版本弄混。

　　2、让头文件和库文件的对应关系一直保持清楚

　　在每个存放库文件的目录里，最好能同时把include、lib以及doc或readme这几个子目录也都保留好，因为一旦头文件的版本和库文件自身的版本对不上号，编译这一步也许还能照样通过，但是到了链接阶段或者实际运行的时候，问题就可能冒出来了，尤其是那些结构体的定义、函数的接口参数、还有宏开关在发生变化之后，旧的库文件往往会悄悄带来很多不容易察觉的隐患。

　　3、把库文件的命名规则统一下来

　　给库起名字的时候，建议把模块的名称、适用的平台、配置的类型还有版本号都嵌进去，比如可以写成lib_diag_tc3xx_rel_v102这种形式，不要图省事只写libcommon或者libutil这样含含糊糊的名字，因为当有好几个供应商交付的库都存在同名的文件时，如果名字起得不清不楚，链接路径的优先顺序就会变得完全不可控。

　　4、把链接的先后顺序固定住

　　对于静态库来说，它们被放置的先后次序经常与符号的解析顺序直接相关，所以基础库、驱动库、中间件库和应用库一定要按照项目组共同约定好的顺序来放置，不能每个人都在自己的工程里随手去调整，当库与库之间存在依赖关系时，就应当把被依赖的那个库放在一个合适的位置上，免得后面出现符号解析缺失或者重复解析的情况。

　　二、重复链接问题该从哪里入手去定位

　　碰到重复链接的问题时，比较常见的现象是编译工具报告符号重复定义，或者同一个函数在好几个目标文件中都被定义了，这个时候不要急着去把某个库直接删掉，而应该先找出那个冲突的符号到底是从哪里来的。

　　1、从链接错误的第一条信息开始查

　　在构建时弹出的信息窗口里，一般会清楚地显示出是哪一个符号发生了重复，以及它分别来自哪一个目标文件或者哪一个库，先把这第一条完整的错误提示原原本本地记录下来，不忙去理会后面跟着的那几十条连带报错，因为多半是同一个根子带出来的，抓住第一个往往就能说清楚真正的冲突源头。

　　2、打开map文件去查符号的来源

　　接着，要在工程的链接选项里面把输出map文件的功能打开，重新做一次完整的构建之后，在生成的map文件里直接搜索那个重复符号的名字，就能看到它到底是被哪个目标文件、哪个库文件给引进去的，map文件还能帮我们判断同一个库是不是被重复加进了工程，或者同一个功能模块是不是同时以源代码和库文件这两种形式参与了链接。

　　3、检查工程里面是不是重复包含了同一份源码

　　很多重复符号的问题，都是因为既把一份源码放进工程里编译了，同时又链接了一个里面已经包含相同模块的库文件，比如driver_init.c这个文件已经在工程里了，而lib_driver.a库里也包含着driver_init.o，那么到了链接那一步就必然会报出重复定义的错误，这时就要在源码方式和库方式这两者之间选一种留下。

　　4、检查供应商提供的库是不是有功能重叠的部分

　　在一些第三方中间件、实时操作系统的适配层，还有芯片厂商提供的驱动库里，很可能各自都带着启动代码、系统调用的封装、内存操作函数或者板级初始化的函数，假如好几个库都定义了相同名称的接口，就应该根据整个项目的整体架构来决定最终保留哪一份，并且在另一侧把重复的那个模块关掉。

　　三、怎样才能让库文件的问题不再反复出现

　　把库文件相关的麻烦事解决一次其实不算太难，真正难的地方在于等到后续版本升级的时候，同样的问题不要再翻来覆去地冒出来，这就要求项目组把库的管理也纳入到构建的规范化流程里面，而不是单靠个别成员的个人经验去扛。

　　1、建立一份完整的库清单

　　在这份清单当中，要记清楚每一个库的名称、版本号、来源、适用的芯片型号、编译时所用的选项、依赖哪些其他库，以及责任人的名字，每次对库文件做升级的时候，都要同步地把这份清单更新一遍，防止工程里留下那些说不清来源的陈旧版本。

　　2、保存好每次构建的链接日志和map文件

　　在生成正式版本的时候，最好把链接时的完整命令、生成的map文件、库文件的列表，还有整个构建的日志一起打包归档，往后一旦发现程序占用的ROM或者RAM空间发生了变化，又或者出现了符号冲突，就可以直接拿前后两个版本进行对比。

　　3、不要使用通配符去盲目加载库

　　别把某一个目录底下所有的库文件一次性都加进工程里去，而是只挑出当前这个目标平台确实需要的那几个库，用通配符一股脑加进来的做法看起来好像挺省事，但稍不注意就会把旧版本、临时测试用的库，还有重复的库一同卷进来。

　　4、库文件升级以后做一次符号抽查

　　每次库文件更新完之后，可以重点去查一查启动函数、中断向量、系统调用、内存管理，还有那些公共的工具函数，如果提早发现了同名的符号，提前去处理，比一直拖到链接阶段才跳出一堆错误要节省很多时间。

　　总结

　　把Green Hills工程里的库文件组织好，需要围绕硬件平台、功能模块、版本号以及构建配置这几样建立一套清晰的目录体系，同时让头文件、库文件和说明文档之间一直保持着准确的对应关系。当遇到重复链接的时候，应该先抓住链接器报出的第一条错误，再利用map文件去定位产生冲突的符号究竟来自哪里，着重去检查同一份代码是不是既通过源码又被包进库参与了链接，以及不同供应商提供的库在功能上是否存在重叠。只要把库清单、链接顺序和map文件这些做法固定下来，后面无论是要迁移工程，还是做版本升级，都会平稳很多，也能少不少来回折腾的麻烦。