我目前正在开发一个灵活的 C/C++ 构建框架，我将(希望)很快将其开源。 (有关一些背景信息，请参阅 this 问题)。
我正在使用以下命令为源文件/头文件生成#include 文件依赖项。
gcc -M -MM -MF
有没有一种方法可以使用 gcc/GNU 实用程序以与上述类似的方式巧妙地推断可执行文件(在我的例子中是单元测试+目标平台的主要可执行文件)的链接器(.o 文件)依赖性？目前，该框架做出了很多假设，并且在确定这些依赖关系时非常愚蠢。
我听说过一种方法，可以使用 nm 命令在目标文件中生成 undefined symbol 的列表。例如，在目标文件(使用 gcc -c 编译)上运行 nm 会得到类似这样的结果 -
nm -o module.o
module.o: U _undefinedSymbol1
module.o: U _undefinedSymbol2
module.o:0000386f T _definedSymbol
然后，人们会寻找其他目标文件，其中定义了这些 undefined symbol ，以得出成功链接文件所需的目标文件依赖项列表。
这是否被认为是确定可执行文件的链接器依赖性的最佳实践？还有其他方法可以推断这些依赖关系吗？在提出您的解决方案时，假设所有目标文件都已存在(即已使用 gcc -c 编译)。
最佳答案
如果有多个可执行文件(甚至一个可执行文件)需要不同的依赖集，那么正常的、经典的处理方法是使用一个库——static .a 或 shared .so(或等价物)— 保存可由多个程序使用的目标文件，并将程序与该库链接。链接器自动从静态存档中提取正确的目标文件。共享库过程略有不同，但最终结果是相同的:可执行文件在运行时具有可用的正确目标文件。
对于任何程序，至少有一个程序唯一的文件(通常是包含 main() 程序的文件)。该程序可能有几个文件。这些文件可能是已知的并且可以很容易地列出。根据配置和编译选项，您可能需要的那些可能在程序之间共享，并且可以通过库机制轻松处理。
您必须决定是要使用静态库还是共享库。创建共享库比创建静态库更难。另一方面，您可以更新共享库并立即影响所有使用它的程序，而静态库可以更改，但只有重新链接到新库的程序才能从更改中受益。
关于c++ - 为 C/C++ 可执行文件自动生成目标文件(链接器)依赖项，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10670409/