Makefile配置：静态库选择、可执行文件strip等技术问题

1. 链接时如何选择静态库而非动态库？ #

• 直接在链接命令中指定静态库的完整路径，强制编译器使用该静态库，跳过默认的动态库查找逻辑：

  c++ ... -o myapp build/C11/gen/*.o ./cpp_runtime/dist/libantlr4-runtime.a
  

• 若用Makefile变量管理依赖，将LIBS或LDLIBS设为静态库路径，而非仅写-lantlr4-runtime（该参数默认优先匹配动态库）：

  ANTLR4_RUNTIME_DIR := ./cpp_runtime/dist
  LIBS := $(ANTLR4_RUNTIME_DIR)/libantlr4-runtime.a
  

• 不推荐使用-static全局静态链接参数，它会将所有依赖（包括系统库）都静态打包，导致可执行文件体积大幅膨胀。

2. 如何直接生成已strip的可执行文件？ #

• 在链接阶段添加-s编译参数，编译器会在生成可执行文件时自动剥离调试符号、符号表等冗余信息，无需单独执行strip命令：

  c++ ... -s -o myapp ...
  

• 在Makefile中可将-s加入LDFLAGS变量，让所有链接规则自动应用该参数：

  LDFLAGS := -s
  

3. 依赖动态库的已strip可执行文件仍有700K大小，原因是什么？ #

• 核心代码不可剥离：Antlr4生成的词法/语法分析器代码是程序运行的核心逻辑，属于可执行文件的代码段（.text），strip只会移除调试符号，不会影响运行必需的二进制代码。
• 动态链接元数据：即使依赖动态库，可执行文件仍需保留动态链接器入口、动态库依赖表、符号引用表等信息，这些是程序启动时加载动态库的必要数据，无法被strip删除。
• 系统基础依赖：程序依赖的libc、libstdc++等系统库的动态链接入口也会占用部分空间，这些内容是运行必需的。
• 全局数据与初始化代码：可执行文件中的全局变量、初始化函数等数据段（.data/.bss）同样是运行必需的，strip不会对其进行处理。

4. 当前编译命令为c++ -c path1/file.cpp -o path2/file.o，每次仅生成一个目标文件效率较低，是否先在原目录生成再移动至目标目录更优？ #

• 效率差异可以忽略：现代文件系统中，直接指定输出目录的写操作开销与“原目录生成+移动”的开销几乎无区别——若同文件系统，mv是元数据操作，几乎零耗时；跨文件系统时，复制+删除的耗时远小于编译本身的耗时。
• 源码目录更整洁：直接输出到构建目录（如path2）可以避免源码目录被目标文件污染，符合构建与源码分离的工程实践，减少清理维护的复杂度。
• 提升编译效率的正确方向：与其纠结输出路径，不如启用并行编译（make -jN，N为CPU核心数），或完善Makefile的依赖管理实现增量编译（仅编译修改过的源文件），这两种方式才能真正大幅提升编译速度。

内容的提问来源于stack exchange，提问作者Saku