自动为C / C ++可执行文件生成目标文件(链接器)依赖项

时间:2012-05-20 02:48:28

标签: c++ c gcc linker dependencies

我目前正在开发一个灵活的C / C ++构建框架,我很快就会(有希望)开源。 (有关背景信息,请参阅this问题)。

我使用以下命令为源/头文件生成#include文件依赖项。

gcc -M -MM -MF

是否有一种巧妙地推断可执行文件的连接器(.o文件)依赖关系(单机测试+我的情况下目标平台的主要可执行文件)的方法,使用gcc / GNU实用程序,方式与上面类似?目前,该框架做了很多假设,并且在确定这些依赖关系时非常愚蠢。

我听说过一种方法,其中 nm 命令可用于在目标文件中提供未定义符号的列表。例如,在目标文件上运行nm(使用gcc -c编译)会出现类似这样的内容 -

nm -o module.o

module.o:         U _undefinedSymbol1
module.o:         U _undefinedSymbol2
module.o:0000386f T _definedSymbol

然后,人们会查找其他目标文件,其中定义了这些未定义的符号 ,以提供成功链接文件所需的目标文件依赖关系列表。

这是确定可执行文件的链接器依赖项的最佳实践吗?有没有其他方法可以推断出这些依赖关系?在提出解决方案时,假设所有目标文件已经存在(即已经使用gcc -c编译)。

3 个答案:

答案 0 :(得分:8)

如果有多个可执行文件(甚至是单个可执行文件)需要不同的依赖项集,那么处理它的常规经典方法是使用库 - 静态.a或共享.so (或等效) - 保存可由多个程序使用的目标文件,并将程序与该库链接。链接器会自动从静态存档中提取正确的目标文件。共享库过程略有不同,但最终结果是相同的:可执行文件在运行时具有正确的目标文件。

对于任何程序,至少有一个程序特有的文件(通常,这是包含main()程序的文件)。该程序可能有一些文件。这些文件可能已知并且可以轻松列出。根据配置和编译选项可能需要的那些可能在程序之间共享,并且可以通过库机制轻松处理。

您必须决定是否要使用静态库或共享库。创建共享库比创建静态库更难。另一方面,您可以更新共享库并立即影响使用它的所有程序,而静态库可以更改,但只有使用新库重新链接的程序才能从更改中受益。

答案 1 :(得分:5)

以下Python脚本可用于收集和处理当前目录中所有目标文件的nm输出:

#! /usr/bin/env python

import collections
import os
import re
import subprocess

addr_re = r"(?P<address>[0-9a-f]{1,16})?"
code_re = r"(?P<code>[a-z])"
symbol_re = r"(?P<symbol>[a-z0-9_.$]+)"
nm_line_re = re.compile(r"\s+".join([addr_re, code_re, symbol_re]) + "\s*$",
                        re.I)

requires = collections.defaultdict(set)
provides = collections.defaultdict(set)

def get_symbols(fname):
    lines = subprocess.check_output(["nm", "-g", fname])
    for l in lines.splitlines():
        m = nm_line_re.match(l)
        symbol = m.group('symbol')
        if m.group('code') == 'U':
            requires[fname].add(symbol)
        else:
            provides[symbol].add(fname)

for dirpath, dirnames, filenames in os.walk("."):
    for f in filenames:
        if f.endswith(".o"):
            get_symbols(f)

def pick(symbols):
    # If several files provide a symbol, choose the one with the shortest name.
    best = None
    for s in symbols:
        if best is None or len(s) < len(best):
            best = s
    if len(symbols) > 1:
        best = "*" + best
    return best

for fname, symbols in requires.items():
    dependencies = set(pick(provides[s]) for s in symbols if s in provides)
    print fname + ': ' + ' '.join(sorted(dependencies))

脚本搜索.o文件的当前目录和所有子目录,为找到的每个文件调用nm并分析结果输出。在一个.o文件中未定义并在另一个*文件中定义的符号被解释为两个文件之间的依赖关系。无处定义的符号(通常由外部库提供)将被忽略。最后,该脚本打印所有目标文件的直接依赖项列表。

如果某个符号由多个目标文件提供,则此脚本会假定依赖于具有最短文件名的目标文件(并在输出中标记所选文件的pick)。可以通过修改函数{{1}}来更改此行为。

该脚本适用于Linux和MacOS,我没有尝试过任何其他操作系统,脚本只是经过轻微测试。

答案 2 :(得分:4)

nm实用程序使用libbfd读取目标文件(和档案,例如.a库)。我在想你真正想要做的是处理你知道的库中定义的公共符号的数据库,以及在这个项目的一部分的目标文件中,以便在生成每个新的目标文件时可以查看其中的未定义符号,并确定需要链接以解析引用的哪个对象(纯文本或库中)。基本上你在做与链接器相同的工作,但是反过来,这样你就可以找到哪些符号。

如果您正在使用GCC,您可以随时查看“binutils”的源包以查找nm的源代码,如果需要,甚至可以查找ld。你肯定不想运行nm并解析输出,只需在引擎盖下使用libbfd,只需自己调用libbfd。