1. 为什么要把C文件变成lib库：适用场景与边界
先说一个我前两年遇到的场景。有个做车载传感器的客户，要把一套电机控制算法集成到他们的主控板上，但算法源码是合作方的核心资产，对方只愿意交付编译好的目标文件，不提供任何一行C代码。两边在会议室拉锯了半天，最后技术对接人问我：能不能把算法工程里的那几个.C文件单独编成一个.lib给他们？
这就是KEIL MDK里最常见的lib库需求来源——源码保密。代码交付、外包协作、方案授权，只要是"东西给你用，但源码不能给你看"的场景，把C文件编进lib库几乎是唯一干净利落的解法。
除了保密，还有两个实际场景我经常遇到：
一是减少重复编译时间。模块多了之后，一个几百文件的大工程，每次改动一个底层驱动就要全量重编，Keil虽然会做增量编译，但遇到头文件牵连面大、或者你开了"Always Rebuild"的时候，一次构建十几分钟很常见。把稳定的模块提前编成lib，主工程里只保留天天改动的部分，编译时间肉眼可见地缩短。
二是模块化团队协作。驱动组写完的BSP、算法组验证过的滤波函数，以lib形式发给应用组，接口用头文件约定清楚，谁都不需要关心别人内部文件的编译顺序和依赖关系。
但我要先泼一盆冷水：lib库这件事，真正干活的时候远没有"把文件拖进去勾个选项"这么简单。KEIL MDK从v5到v6，工程配置、编译选项、链接行为都有不少差异，同一个操作在AC5和AC6下结果可能完全不一样。网上搜得到的教程大多只讲了"新建lib工程然后编译"，根本没提那些在你真正集成的晚上把你折磨到凌晨两点的坑。
所以这篇文章不是教你点按钮，而是把从工程配置、批量构建到排查链接错误这整条链路完整走一遍。你不需要是高手，只要手头有MDK 5.3x以上的版本就行，我尽量做到每个操作都告诉你为什么这么做。
1.1 三个我实际遇到过的场景
场景一：算法交付。对方要你的滤波器、FFT、PID这些核心算法，用lib交付，只给一个algo_export.h的头文件，里面声明接口函数，不暴露内部静态函数和全局变量。这是最经典的需求。
场景二：驱动分发给多个子公司。同一个BSP源码，五六个不同产品的工程都要用。源码分发后每个工程都来改两行，版本立刻混乱。编成bsp_driver.lib之后，内部实现随便改，只要接口不变，下游工程只需要替换lib文件，一行代码都不用动。
场景三：我只改动应用层，不想每次重新编译整个中间件。中间件层编成lib，工程里保留应用代码，每次构建只编应用层那几十个文件，Keil的构建速度从几分钟降到十几秒。这个场景很多人忽略，其实对日常开发体验的提升是最直接的，而且实现成本最低。
1.2 lib库和单个.o文件有什么不一样
很多从GCC转过来的老手会问一个问题：我直接给出编译好的.o文件不就行了，为什么非要打包成lib？
理论上确实可以，Keil在"Create Library"模式下生成的每个目标文件本来就是.o（在MDK的Bulk文件夹里可以看到），把一堆.o直接发过去，链接器也能用。但实际工程里没人这么干，原因有几个：
一是多个.o的集合需要一个索引机制，否则链接器逐个扫描.o文件效率极低。lib库本质上就是ar -r打包出来的一个归档文件，内部包含多个成员模块，还有符号索引表。链接时，链接器只需要查索引表，看哪个需要的外部符号在哪个成员里，把对应成员拉进来即可。
二是库的链接行为有特殊的按需提取语义。链接器不会把lib里所有代码都塞进最终镜像，而是只提取能被解析当前未定义符号的那些成员模块。这意味着你可以在库里塞一堆驱动模块，最终用户就算只用了其中一个函数，最终烧写的Flash也只有那一个模块的代码。单独的.o文件不具备这个特性，只要你把它作为目标文件传给链接器，它就会全部进镜像。
顺便说一个我经常看到有人搞错的点：Keil编译lib工程，本质上做的就是把一堆.C文件分别编译成.o文件，然后调用ARM库管理工具把这些.o归档进一个.lib文件。中间没有链接这一步。这一点后面排查很多问题的时候都很关键。
1.3 不适合用lib库的情况
不是所有代码都适合编成lib，这个边界要在动手之前就清楚：
与链接地址强相关的代码：如果你的代码里有
#pragma arm section code=".my_section"这种段定位植入，或者用了分散加载文件里对dataloc的绝对地址定位，把它编成lib后，段定位信息可能丢失或错乱。ARMCC在生成库成员时，某些section属性会按保留方式处理，最终用户的分散加载文件里不一定能命中你期望的段名，排查起来非常痛苦。带启动代码和底层汇编初始化的板级文件，比如
startup_xxx.s、system_xxx.c中的SystemInit。这些文件建议保持源码形式留在最终工程里，因为它们跟具体芯片型号、启动地址强相关。你就想想，一个lib库里面带着Reset_Handler，如果用户的工程也有一个Reset_Handler，链接器到底该用哪个？这就是直接埋雷。需要频繁用宏配置的功能。如果你的驱动代码大量依赖外部的配置宏，比如
#define TCP_RX_BUFFER_SIZE 2048，这种宏在编译期就被决定了，用lib交付后，用户想改配置就只能来找你重新编译。换句话说，lib把编译期自由度锁死了。
2. 编译lib库的工程配置：一步一步来
现在进入正题。我假设你已经在MDK里有一个正常的应用工程，里面有一组C文件要变成lib，另外有一些文件必须留在源代码里。下面这套步骤就是我实际用下来最顺利的流程。
2.1 新建或改造工程：分组是第一步
最稳妥的做法是先复制一个现有工程，再在这个副本上改成lib工程，不要在原工程上直接改。因为生成lib的工程配置跟正常应用工程差别很大，你在副本上随便折腾都不影响原来的应用工程。我吃过亏：直接在原工程上改了输出选项，结果忘了改回来，第二天所有人编译出来的都是跟lib一样没有链接的中间文件，链接器跑到最后直接报错，一上午白费。
复制好之后，打开Manage Project Items（就是那个有三个方块叠一起的图标），在Project Targets里新建一个Target，比如叫my_module_lib。在Groups里按模块新建分组，把要编成lib的.C文件拖进去。
这里有一个很重要的点：只把要编进lib的C文件所在的组保留为"参与构建"状态，其余组全部右键选择"不勾选"。Keil里每个文件或组都有一个复选框，勾选表示参与当前Target的编译。lib工程里如果还有main.c、startup_xxx.s这些文件参与编译，它们也会被编进lib里。虽然不一定会引发直接错误，但会让lib体积变大，还有可能跟最终工程的启动代码产生符号冲突。
所以正确做法是：
- 把要进lib的C文件放一组，保持勾选。
- 所有不需要的组（应用层、启动文件、中间件源码）全部取消勾选。
- 头文件所在的Include Path不管它，反正头文件不会进lib，它只是在编译时被读取。
2.2 输出配置：从Executable切换到Library
在Options for Target的属性页，切到Output标签页，关键操作来了：
- 文件夹：设置lib文件的输出路径，建议用
.\Output\并单独建一个Lib子目录。 - Name of Executable：虽然显示是"可执行文件"的名字，但这里实际是输出lib的基名。比如填
my_module_lib，最终生成的lib文件是my_module_lib.lib。 - 然后是最关键的：勾选Create Library。
这一步很多人找不到，因为它藏在一个下拉列表里，默认显示的是Create Executable。切换成Create Library后，你会发现原来那些"Debug Information"、"Browse Information"这些选项还在，但"Linker"标签页里很多东西变得不可用了。这是因为lib模式根本不会启动链接器，整个构建只做编译和打包两个阶段。
注意，Create Library这个选项在ARMCC和ARMCLANG下的表现形式略有不同，ARMCLANG（v6）不一定显示"Create Library"字样，可能是一个Candidate Configuration的选项，这个我们下一节细说。
切换完成之后，先做一次Build（不是Rebuild，增量构建就行）。如果工程里还有已经被取消勾选的文件组，构建时会看到Keil提示"skipped"，这是正常的。构建结束后去lib输出路径看一眼，会发现生成了xxx.lib文件。
2.3 ARMCC和ARMCLANG的分支处理
这是KEIL最近的版本里最让人踩坑的地方。MDK 5.36之后，新安装的MDK默认编译器是AC6（ARMCLANG），传统的AC5（ARMCC）需要通过Pack Installer手动安装ARM Compiler 5，而且默认的编译器选择可能在pack页面里找不到。
先说结论，在AC5模式下，你要生成lib，Options for Target -> Output勾选Create Library即可，生成的lib链接行为如下：
- 编译阶段：每个C文件编译成.o
- 归档阶段：用armar工具把这些.o归档进.lib
在AC6模式下，事情有一丁点变化。ARMCLANG的编译器选项里有个-lib的语义，但MDK的图形界面一般不直接让你看到。在AC6下依然是勾选Create Library，但有个额外的问题——AC6的调试信息格式和兼容性。如果你在生成库时勾选了Debug Information，最后用户那边链接后想单步调试，你会发现有些符号能看有些符号是空的，原因是AC6的DWARF调试信息里，库成员的单步调试依赖用户的link time optimization开关。这个后面还会展开。
我自己在AC6下遇到过一个问题：Create Library勾上了，但在某些兆易创新、新唐的芯片Pack版本里，Target属性页的Output下拉列表里直接没有Create Library这个选项，只有Executable的一个变体。后来排查发现是Pack版本太旧，把Keil升级到5.37并把Device Pack更新到最新就正常了。如果你也卡在这，先检查Pack版本，别急着卸载重装。
2.4 头文件路径、宏定义与C标准开关
生成lib只有编译阶段，所以所有编译期依赖必须在这个阶段解决完整，否则进不了lib。
头文件Include Path这一项，我强烈建议全部改成相对路径。无论是.\..\Inc这种写法，还是..\..\Modules\Common\Inc这种，都要保证在工程文件所在目录偏移的位置能定位到头文件。为什么？因为你的lib最终是要发给别人用的，如果Include Path里有一个C:\Users\zhang\Desktop\project\Inc这种绝对路径，这个路径在作者本机上能编过，一旦换个同事的电脑，打开工程第一秒就报头文件找不到。
这还算好的，更隐蔽的是：这个工程你自己编lib的时候没问题，因为路径存在；但用户拿走后，就算他重新建一个Application工程引用你的lib，也要单独把lib对应的公开头文件路径加到他工程的Include Path里。如果你当初编译lib用的头文件和交付给用户的头文件不是同一份，那就完全是两套ABI，链接器不报错都属于运气好。
宏定义方面，涉及两类宏：
- 影响编译行为的宏，比如
_GNU_SOURCE、__STM32F1_H、USE_HAL_DRIVER，这些必须在lib工程里定义正确，否则编译出来的代码跟你源码工程里编译出来的行为不一致。 - 厂商SDK里的宏，这里有个特别常见的坑。比如你编一个STM32的驱动lib，编译时需要
USE_HAL_DRIVER，而且STM32F103xB这种芯片型号宏用来选择寄存器映射。如果你在lib工程里宏定义的是STM32F103xB，而这个lib最终用在了STM32F103xE的工程里，链接不会报错，但运行起来外设完全错乱。芯片型号宏是编译期锁死的，这一点在交付前一定要写明配套型号范围。
C标准这块，AC5默认是C90，AC6默认C11但兼容GNUC的很多扩展。如果你的C文件里有//注释、for(int i=0;)这种C99语法，在AC5下必须打开C99 Mode。AC6一般不用特别开。用AC6编译老代码报implicit declaration of function这类错误时，不要只想着加头文件——大概率是代码用了C99的隐式声明语法，而AC6的语法检查比AC5严格得多。
3. 效率与扩展：多lib库、命令行构建与工程组织
上面讲的都是单工程的玩法。实际项目到了中后期，你可能要同时维护好几个lib：一个算法库、一个BSP库、一个中间件库，再加上一个总的应用工程。这一节聊的是怎么让这套流程高效运转起来。
3.1 一个工程只能产出一个lib，多个lib怎么组织
先说结论：MDK一个工程一次构建只能生成一个lib文件，lib名字就是Options for Target -> Output -> Name of Executable里填的那个基名。你想在一个工程里既生成A.lib又生成B.lib，做不到。
那多个lib怎么管理？两个方向：
方向一：用多个Target管理。在Manage Project Items里，一个Project下可以建多个Target，给每个Target配上不同的分组组合和lib输出名。比如Targetbsp_lib生成bsp.lib，Targetalgo_lib生成algo.lib。每次构建时到Target下拉列表里切一下就行。
这个方案的好处是工程文件只有一个，版本管理简单；缺点是Target一多，配置很容易互相污染——你在这个Target里加的宏定义、Include Path，切到另一个Target时可能因为Copy配置的操作不当，导致多了或者少了几个选项。我的习惯是：建好第一个Target并配好所有选项后，用Copy按钮逐项确认复制，再逐项修改差异项，千万不要直接全选复制。
方向二：用多个工程文件，一个application工程，一个或多个Module工程。这个方案适合团队组织非常清晰的场景，每个lib独立演进、独立版本号。代价是打开窗口多了，每次都要切工程。我在做大项目时通常同时开两个MDK实例：一个专门看应用工程，另一个专门改模块lib工程，中间用SourceInsight看代码，这样窗口虽多但有分工，反而不乱。
3.2 用UV4命令行批量构建
如果只是偶尔编一次lib，在IDE里点一下构建按钮就够了。但如果你需要每天下班前出一版全量lib给测试组、或者要同时编十几个模块lib，手动切Target再点按钮，总有一天会漏掉一个模块。
KEIL的编译其实有命令行接口，狂人不多知道。在Keil安装目录下有个UV4.exe（新版可能是UV5.exe），调用方式如下：
"C:\Keil_v5\UV4\UV4.exe" -b "D:\projects\my_module\my_module.uvprojx" -t "algo_lib" -o "D:\projects\my_module\build_algo.log"参数解释一下：
-b：进入批处理构建模式，不打开GUI。-t：指定要构建的Target名称，必须是工程里实际存在的Target名字。-o：输出日志文件的路径。如果没有这个参数，UV4会弹出一个简短的对话框显示结果，但批处理模式下你根本看不到，所以一定要指定log文件。
构建完之后，用%ERRORLEVEL%判断结果。UV4的这个返回值是0到4的映射，0表示成功无警告，1表示成功有警告，2表示失败有错误，3表示运行了但出现致命错误，4表示UUID错误（工程文件被锁定或IDE占用）。批处理脚本里只要判断不等于0或1就发告警。
我来给出一个实际的批量构建脚本示例（Windows批处理）：
@echo off set UV4="C:\Keil_v5\UV4\UV4.exe" set PRJ="D:\projects\my_module\my_module.uvprojx" %UV4% -b %PRJ% -t "bsp_lib" -o "D:\projects\build_logs\bsp.log" if %ERRORLEVEL% gtr 1 ( echo [FAIL] bsp_lib build failed, code %ERRORLEVEL% ) else ( echo [OK] bsp_lib ) %UV4% -b %PRJ% -t "algo_lib" -o "D:\projects\build_logs\algo.log" if %ERRORLEVEL% gtr 1 ( echo [FAIL] algo_lib build failed, code %ERRORLEVEL% ) else ( echo [OK] algo_lib )这个脚本还可以继续扩展，比如构建完成后自动把生成的lib文件拷贝到一个release目录，按日期打标记。我自己的做法是在脚本末尾加一段copy命令：
set RELEASE=H:\release\%DATE:~0,4%%DATE:~5,2%%DATE:~8,2% mkdir %RELEASE% 2>nul copy /Y D:\projects\my_module\Lib\bsp.lib %RELEASE%\bsp_%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%.lib这样每次构建出来的lib不会被覆盖，联调时出问题还能精确回溯到是哪一天的库。
3.3 让脚本接管重复劳动的思路
做嵌入式的大多数人不会用Jenkins，但如果你折腾过GitLab CI或者Git hooks，就很容易理解这套思路。我给中等规模的团队一个实用方案：
在Git仓库里放一个build_all.bat，每次合并分支后双击一下，自动把BSP、算法、中间件三个lib全部构建一遍，再把lib文件拷贝到共享目录。这套流程之下，任何团队成员拿到最新代码后，只需要更新lib，不用重复编译稳定模块，效率提升非常明显。
如果环境里装了CMake，那还能更进一步。但说实话，Keil工程用CMake重新复刻一份构建脚本的成本，大多数团队都hold不住，强行做反而会造成两份构建体系互相矛盾。我的建议是：除非是跨平台产品线，否则老老实实用UV4命令行。简单一点，出问题概率就低一点。
4. 避坑专题：我踩过的和帮别人排过的坑
这一节是整篇文章的精华。前面讲的是"怎么把lib编出来"，这一节是"为什么我编出来了，用的时候还是炸了"。每一条都来自真实项目经验，我尽量把排查链路完整写出来，而不仅仅是给个结论。
4.1 lib里没有符号？先查编译器类型差异
现象：你编好了一个lib，在应用工程里include了对应头文件并调用函数，链接时报Undefined symbol xxx。
排查链路：
- 第一步当然是打开lib文件确认里面有没有这个符号。用fromelf工具（在Keil安装目录的ARM\ARMCC\bin或ARM\ARMCLANG\bin下）查看：
fromelf -s my_module.lib如果fromelf不认这个lib文件，弹出各种奇怪的解析错误，那很可能是lib的格式跟你当前编译器不兼容。ARMCC生成的lib和ARMCLANG生成的lib内部的对象格式不同。
这种不兼容最常见的原因是：你的lib是用AC5编的，而应用工程用的是AC6。虽然两者的最终链接器都能处理一定程度的兼容，但库成员的对象格式差异会导致链接器不识别或符号规则不一致。
还有一种情况是符号存在但链接器找不到，比如lib里的符号带了额外前缀。AC5有一个编译选项
--library_interface或者可能因为decorate选项导致符号修饰差异。排查办法是看lib输出的符号名，然后看应用工程里引用的符号名，把两个清单比对一下，如果是符号名不匹配，要么在lib工程里关闭相关选项重编，要么在应用工程里改成匹配的调用方式。
我自己遇到过一次最离谱的情况：lib里有个函数叫Motor_SetSpeed，应用工程里怎么链接都是Undefined symbol Motor_SetSpeed，后来用fromelf把lib符号全量导出来一看，符号名是Motor_SetSpeed$P，多了一个尾缀。原因就是lib工程里勾选了一个编译选项，导致符号经过寄存器参数优化后加上了特殊标记。所以看到$、$$、?这类符号再别慌张，先用工具看清楚再动手。
4.2 头文件路径的绝对路径陷阱
现象：库作者在本地编译一切正常，交付lib附带头文件，用户打开工程，#include "module.h"报错找不到文件。
原因极其常见：库作者的lib工程里，Include Path填的是绝对路径。编译lib时这个路径在那个作者的电脑上当然存在，但lib编译完之后，这个绝对路径并不会被烧进lib里——它只是在编译时用来定位头文件的。问题是，交付使用的时候，用户的工程需要的是lib对应头文件的公开声明，他必须能用自己的相对路径找到这个头文件。
更坑的是，有些头文件里互相引用的路径也是绝对路径。比如#include "D:\proj\common\types.h"，这在GCC下有些版本直接报错，在Keil下也不会安静通过。我处理这种问题的方式是：在工程根目录建一个PublicInc目录，把要公开的头文件集中放进去，lib工程和用户工程都只把.\PublicInc加入Include Path，禁止任何头文件用绝对路径引用其他路径。
交付前的自检清单：
- 在你的lib工程里，把Include Path全部改成相对路径。
- 把lib工程编译出来的结果，连同PublicInc目录一起拷到一台干净的电脑上，单独建一个应用工程引用这两个东西，能编过才算合格。
- 检查PublicInc里的头文件，看它们自身的
#include语句是否全都是相对形式的。
4.3 Reference Missing：用fromelf把lib扒开看
现象：应用工程链接时报Reference Missing: 某某函数，但这个函数确实在lib里，而且你已经include了头文件。
这种问题的排查链路，我很建议把它做成一个标准动作：
第一步，确认这个函数有没有被static修饰。如果函数的定义在源文件里是static的，它就是文件内部符号，外部无论如何都链接不到。lib里的符号表里根本不会有它。这种情况不是坑，是你代码本身的封装问题。
第二步，确认函数有没有被条件编译排除。常见于#ifdef XXX_ENABLE包起来的函数，编译lib时没定义这个宏，函数自然没编进去。检查lib工程编译时的宏定义，再对照源码里的条件编译指令。
第三步，用fromelf导出lib的全部全局符号，比对调用名称：
fromelf --text -s my_module.lib > symbols.txt打开symbols.txt，搜索你需要的函数名。如果搜不到，说明这个函数确实没编译进去；如果能搜到，注意看符号名后面跟的是CODE还是DATA，以及是否存在前面说的修饰后缀。
第四步，还有一种很隐蔽的情况：函数定义在lib里，但lib的成员没有被链接器选中。前面说过，lib是按需提取的，如果lib里成员A引用了成员B，链接器提取A时会连带提取B；但如果没有任何已提取成员引用成员B，而且应用工程也没直接引用B，那B就永远不会被链接进来。这时候你如果确定需要B，就在应用工程里显式引用它，或者把需要导出的函数做成一个导出入口页面对齐。
4.4 MicroLIB与printf重定向的冲突
这是个经典问题，给它单列一节都不过分。
现象：应用工程勾选了Use MicroLIB，用lib里封装的printf函数（或者更准确说，lib里的某个模块通过printf做日志输出），结果程序跑起来什么日志都没有，或者进HardFault。
原因：Keil的MicroLIB是一个精简C库，它里面的printf跟标准C库的printf在I/O重定向链路上有差异。MicroLIB的底层写字符函数是fputc，但它重定向时依赖你提供一个叫fputc或者_sys_write的实现。如果你的lib模块里直接调用了printf，而这个printf最终要在RAM的某个缓冲或者UART上输出，你必须提供底层函数。
但坑在于，你在应用工程里写了底层的fputc实现，而这个实现的符号声明、FILE结构体定义在MicroLIB里跟标准库不一样。如果你的lib里有些文件是标准C库编译路径、有些是MicroLIB路径，两者混在一起，链接阶段可能因为__stdout符号冲突、FILE结构体大小不一致而报奇怪的地址错误。
我的做法是：凡是会输出日志、会调用printf/sprintf的模块，不建议编成lib交付，或者一定要在交付文档里写清楚"依赖MicroLIB的fputc钩子函数"。如果非要封装到lib里，建议在lib内部提供一个原始的log_output(const char *fmt, ...)机制，把格式化放在lib里，把底层写字节的钩子暴露出去，让用户自己实现：
/* 在lib里提供 */ void log_set_output(void (*output)(char ch)); void log_info(const char *fmt, ...);这样lib内部完全不依赖MicroLIB的stdio链路，把最麻烦的底层重定向问题留给应用层，这是我在实际项目里验证过的干净解。
4.5 启动文件与main的问题
很多人第一次编lib工程时会想：lib不是最终镜像，我不需要main，也不需要启动文件。这个想法大方向没错，但有一个容易忽略的细节。
生成lib的构建只做了编译和归档，链接器不跑，所以不报缺main的错误。这确实。但如果你把启动文件、system_xxx.c这类文件也勾选参与了编译，它们会被编进lib。最终用户链接他的应用工程时，链接器在解析Reset_Handler、SystemInit这些符号时，如果用户工程自己也有同样符号，链接器一般优先选择用户直接提供的目标文件，而不是lib里的版本。但如果用户的工程里恰恰没有定义SystemInit，而你的lib里有，链接器就会从lib里提取这个成员，把启动文件的一部分逻辑带进来，跟用户自己的启动流程混在一起，出现非常诡异的初始化顺序问题。
解决方式也简单：lib工程里，与启动相关的文件全部取消勾选，只保留你要封装的功能模块。在编译阶段，头文件路径里可以保留芯片SDK的路径，因为你的功能模块代码可能依赖芯片寄存器定义；但启动文件、链接脚本、分散加载文件这些，永远不要让它们出现在lib工程里。
还有一个相关的问题：如果lib里的某个模块在某个函数内定义了静态变量，而这个模块不想被用户依赖启动文件初始化，就要注意__attribute__((zero_init))或者__attribute__((section(".bss")))这类处理。Keil下零初始化变量的默认行为依赖C库的启动代码，如果你的lib被用在了一个没有正常初始化bss的环境（比如某些bootloader场景），静态变量初始值可能不是0，这属于高级话题了，但做bootloader开发的同学一定要留意。
另外补充一条：lib工程里没有main并不代表可以在任意文件的任意函数里写int main()。如果你的lib里真的包含了一个main函数符号，用户工程里也有main，链接器在解析这个符号时会遇到多定义冲突，报L6200E: Symbol main multiply defined。别笑，我见过把测试用的main函数忘在模块文件里就发布lib的，用户那边一链接就炸。
4.6 ARMCC的段名调整在lib模式下失效
最后说一个相对冷门的坑，但碰上一次就够你折腾半天。
ARMCC提供__attribute__((section("name")))和#pragma arm section这种机制，可以把变量放到指定的section里，比如#pragma arm section zidata = "NoInit_RAM"用来放置那些掉电不丢失的变量。这种写法在正常编译成可执行文件时，配合分散加载文件是有效的。
但当你把这段代码编进lib再给别人用时，目标文件里的section信息确实还保留着，但最终链接时，分散加载文件是在用户的链接阶段指定的。如果你的section名跟用户的分散加载文件名不一致，链接器要么找不到合适位置，要么按默认规则放置，效果就跟你预期完全不同。这还不算什么大问题，真正麻烦的是ARMCC的某些section属性在库归档过程中会丢失，特别是遇到dataloc这类绝对地址定位指令时，编译器可能会直接报错。
排查建议：如果遇到lib模式下的dataloc编译错误，先把文件移出lib工程，改成源码方式编译进应用工程。如果确实需要封装为lib，就要放弃绝对地址定位，改用链接期定位，比如在用户工程里用分散加载文件的OVERLAY功能，或者考虑加一层地址适配层——这就是为什么有些bootloader方案里，地址相关的中间层代码只能以源码交付，这不算技术短板，而是方案取舍。
5. 最后的实操建议
写到这里，关于KEIL MDK下把C文件编译成lib库的技术链路基本上说透了。最后给还在实际动手的读者几个建议，都是我个人反复使用了很久的东西：
第一，编lib之前先把这份lib要发布的头文件写好。接口头文件里只放外部可用的函数声明和数据结构，内部全局变量、内部宏全部藏进源文件或_internal.h。我见过太多人编好lib才发现头文件里漏了一个函数声明、或者暴露了一大堆内部全局变量。
第二，lib交付时一定要附带编译器版本和宏定义说明。AC5还是AC6，有没有开C99、有没有定义芯片型号宏，这些信息写在一张README里。你多发一行字，用户那边就少一次深夜呼叫。
第三，拿到一个别人给的lib，自己struggle排查半天前，先用fromelf把符号表导出来看看。大多数"符号找不到"的问题都能在符号表里看到真相，省下大量瞎猜的时间。
第四，如果你要长期维护多个lib，从第一天就养成用命令行批量构建的习惯。虽然IDE方便，但当构建链路上有了脚本，你就可以把它接到版本控制的提交校验里去，这跟我开头说的"下班编一版"的痛点彻底拜拜了。
做嵌入式的东西，能亲手把一套链路从代码编译到库封装到用户集成全部理顺，你对整个构建体系的理解会上一个台阶。这些坑我自己都踩过，希望写出来能帮你少踩几个。
