列表“；从不与“链接”；C项目中的源文件

我想知道是否有人知道检索链接器用来生成可执行文件的文件列表的技巧

一定存在某种解决办法。静态源代码分析器或黑客，例如使用一些奇怪的标志编译，并使用其他工具分析生成的可执行文件，或强制链接器输出此信息

目标是提供一个工具，从源文件列表中删除无用的源文件

最终目标是通过允许他给出可用源文件的列表来简化构建过程。然后，我的工具将只编译链接器实际使用的链接器，而不是所有的链接器

这将允许某些单元测试仍然可以运行，即使有些单元测试已损坏且无法编译，同时不要求用户在cmake中手动列出每个测试依赖项

我现在的目标是linux，但我对将来在其他操作系统上做同样的事情很感兴趣。因此，我想要一个跨平台的解决方案，尽管我怀疑我是否会拥有它：）

谢谢你的帮助

编辑，因为我看到它令人困惑，我所说的

允许他给出可用源文件的列表

例如，在cmake中就是这样。如果使用

add\u可执行文件（名称、源文件）

，则源文件被视为要编译和链接的源文件

---

我想包装

添加可执行文件

，因此

源文件

被视为一组必要时可用的源文件。

我担心检测从未链接的源文件的想法并不有效

要构建程序，如果CMake不链接生成的对象，它将不会编译源文件 文件输入到程序中。我能理解你怎么会认为这会发生，但事实并非如此

CMake已经做了您希望它做的事情，而回到以前的所有其他构建自动化系统也是如此 他们的发明是在20世纪70年代。一切的根本目的 这样的系统是为了确保一个程序的建设 编译源文件

名称。（c | cc | f | m |…）

当且仅当 对象文件

name.o

将链接到程序中 并且已过时或不存在。你总是可以通过 项目的构建规范（CMakeLists.txt、Makefile、SConstruct等）的编码非常糟糕， 但有了CMake，你就需要真正尝试去做，而且 非常熟练地尝试

如果您不希望编译

name.c

和对象文件

name.o

链接到目标程序，则不告诉构建系统

name.o

或

name.c

是该程序的先决条件。别告诉我 你知道的不是真的。基本的能力是不指定重复的先决条件 构建系统目标

链接器将其所有输入对象文件链接到输出中 毫无疑问的节目。它不会问他们是否“需要” 因为它不能回答这个问题。都不是 链接器或任何可能的静态分析工具都不能知道什么程序 当您输入一些对象文件进行链接时，您打算生成。 只能假设您打算制作 这些对象文件链接的结果，假设 联系是成功的

如果这些对象文件根本无法链接到程序中，链接器将告诉您 这就是为什么。否则，如果您链接了未链接的对象文件 想要链接，你只能通过注意自己来发现 生成日志中的错误，或通过测试程序和/或检查其内容并进行比较而失败 你的观察和你的期望

如果您选择了用于链接的对象文件，则可以指示链接器 若要检测任何代码段或数据段，它将在中提取这些对象文件 没有定义可供程序引用的符号，以及 扔掉所有这些未引用的输入部分，而不是链接它们 进入程序。这称为链接时间“垃圾收集”。你告诉警察 链接器通过在

gcc

linkage命令。看见 学习如何最大限度地回收垃圾。这就是你想要的 可以从链接中删除冗余的目标代码

但是，只有当程序 动态不透明，即未与选项链接 ：则程序静态图像中定义的全局符号不可见 到操作系统加载程序，并且不能从其静态映像外部被动态 在相同的过程中使用库。在这种情况下，链接器可以通过静态 一种符号，其定义未在程序的静态文件中引用 图像根本不能被引用，因为它不能被动态引用， 如果输入部分中定义的所有符号都是静态未引用的，那么 它可以对该部分进行垃圾收集

如果程序已链接到

-rdynamic

，则

-Wl，-gc节将
不收集垃圾，这是非常正确的，因为如果程序
如果不是动态不透明，那么静态分析就不可能确定
无法引用在其链接中定义的

值得注意的是，尽管
-rdynamic
不是默认链接
选项，它是使用
GCC工具链。因此，在CMake项目中使用linktime垃圾收集
您必须始终覆盖
-rdynamic
默认值。很明显，这只会
如果您已确定该程序可以运行，则执行此操作是有效的
动态不透明。
这将是非常特定于工具的。FWIW，我使用的
c
编译器只包含显式的源文件