我有一个嵌入式C应用程序，它是使用CrossWorks for ARM工具链开发的。
这个项目的目标是一个特定的处理器，它越来越旧，很难找到，我们正在努力用一个新的处理器来修改我们的设计。因此，我的计划是将源代码分为一组针对旧处理器的低级别驱动程序代码和另一组能够在两个处理器上编译的通用代码。
我开始做一个驱动程序项目，它可以编译成drivers.a文件。目前这个文件实际上是空的。它的全部内容都是
!<arch>
我遇到的问题是，将这个文件包含在公共代码的编译中会导致编译后的大小膨胀。得到的二进制大约大33%。。。
以下是地图文件中一些部分的大小示例，列出的符号是FatFs函数。
Size without drivers.a Size with drivers.a
f_close 76 f_close 148
f_closedir 84 f_closedir 136
f_findfirst 48 f_findfirst 108
f_findnext 116 f_findnext 144
f_getfree 368 f_getfree 636
f_lseek 636 f_lseek 1,148
f_mkdir 488 f_mkdir 688
f_mount 200 f_mount 256
f_open 1,096 f_open 1,492
f_opendir 324 f_opendir 472
f_read 564 f_read 1,132
f_readdir 176 f_readdir 268
f_stat 156 f_stat 228
f_sync 244 f_sync 440
f_unlink 380 f_unlink 556
f_write 668 f_write 1,324
很明显，由于额外的驱动程序.文件，链接器无法确定代码的某些部分是不可访问的，因为链接的驱动程序可能会调用这些例程。我想这是有道理的，但我需要一种方法来绕过它，这样我就可以将代码划分为可单独维护的代码，同时仍然像以前一样高效地进行编译。
我没有意识到链接*.a文件可能会产生这样的后果，我以前在脑海中有这样的想法，即*.a文件与一堆*.o文件没有什么不同，它们有效地组合成一个文件。显然情况并非如此。
事实证明，这与驱动程序中的粉状链接无关。a文件。。。
当我加入驱动程序时，我让项目设置编译器选项的方式发生了变化。a.实际上，我相信我实际上是在比较调试级别3和调试级别2，在这种情况下，添加的二进制大小是可以理解的。