关于通过中间object file实现嵌套链接的可行性、应用场景及相关技术问题问询

我一直在琢磨链接器的一种进阶用法：嵌套链接——也就是让链接器输出未完全解析符号的目标文件（而非直接生成可执行文件、静态库或动态库），用这个中间目标文件参与后续的链接步骤。通常链接器只会被调用一次，但在复杂的软件组合场景下，这种嵌套的链接流程似乎能解决一些单一链接步骤无法处理的问题。想和社区聊聊这个思路的可行性、潜在价值，以及相关的技术细节疑问。

核心思路与预期价值 #

通常链接器的工作是解析符号引用、合并目标文件，但如果能让它输出“半链接”的目标文件，我们就能实现：

• 细粒度的符号隔离：将部分输入目标文件的符号合并后隐藏，不再暴露给后续链接步骤——比如把原本全局可见的符号改成内部可见，避免后续链接时的符号冲突，同时保留指定符号的全局可见性。
• 跨翻译单元（TU）的优化机会：结合-flto（链接时优化），原本因属于不同TU而无法做的内联、死代码消除等优化，现在因为符号被合并到同一个“逻辑TU”中，就可以执行了。
• 模拟嵌套命名空间：不需要语言层面支持，通过嵌套链接将一组符号打包成“逻辑子模块”，对外只暴露指定的接口符号。
• 并行化构建：将大的链接任务拆分为多个小的中间链接步骤，并行执行，提升构建效率。

预期的符号可见性变化（附代码示例） #

为了更清晰地说明，我准备了一组简单的C代码示例，以及预期的嵌套链接流程：

源文件示例 #

// a.c
int a = 0;
static int b = 0;
static void foo() { ... }
void bar() { ... foo(); ... }

// b.c
extern int a;
static int b = 5;
static void foo() { ... }
void baz() { ... foo(); bar(); ... }

// c.c
int a = 0;
static int b = 0;
static void foo() { ... }
void bar() { ... foo(); ... }

// d.c
extern int a;
static int b = 5;
static void foo() { ... }
void baz2() { ... foo(); bar(); ... }

预期的嵌套链接流程 #

1. 第一步：生成中间目标文件
   • 将a.o与b.o链接为x.o：
     • 原本a.c中的全局符号a、bar变为内部符号（不再出现在x.o的符号表中）
     • b.c中的baz保留全局可见性
     • 两个文件中的static符号（b、foo）合并后完全隐藏，不会暴露给后续链接
   • 同理，将c.o与d.o链接为y.o
2. 第二步：生成最终可执行文件
   • 将x.o与y.o链接为最终可执行文件foo，此时只有x.o的baz和y.o的baz2是全局可见的，其他符号均已被隔离隐藏。

注：这种方式无法使用-Bsymbolic和共享对象，因为我们需要精准控制符号可见性，而非一刀切的符号绑定。

待确认的技术问题 #

我有几个关键疑问想请教大家：

1. 链接器的输出能力：主流链接器（如GNU ld、lld）是否支持输出这种“半链接”的目标文件？也就是未完全解析所有符号，但已经合并了部分输入目标文件的符号、调整了可见性的目标文件？（静态库只是目标文件的容器，没有合并符号；动态库是为运行时链接准备的，不符合需求）
2. 符号可见性的精准控制：能否通过链接脚本实现上述的符号可见性调整？比如指定某些全局符号变为内部符号，同时保留其他符号的全局可见性？
3. 与链接时优化的兼容性：如果结合-flto，这种嵌套链接能否触发原本跨TU无法实现的优化（如内联）？因为此时被合并的符号属于同一个“逻辑TU”了。
4. 与单一链接步骤的差异：除了并行化构建、内存占用差异外，这种嵌套链接的最终结果和一次性链接会有哪些实际区别？会不会有未预期的运行时行为？
5. 现有工具与研究支持：
   • 这个思路是否已经被讨论或实现过？有没有相关的技术论文、工具或构建系统支持？
   • 我是否对“链接属性”、“翻译单元”等术语的理解有偏差？（之前有人指出我可能误用了这些术语：根据定义，链接属性描述名称在整个程序或单个TU中是否指向同一实体，而我想实现的是在链接步骤中以符号为粒度调整“逻辑TU”的范围）

无法用单一链接步骤解决的场景 #

我认为这种嵌套链接的核心价值在于解决单一链接步骤无法处理的场景：

• 重叠的符号可见性需求：单一链接步骤只能提供per-TU（static）、per-library（如静态库的符号）、per-program（全局）三级可见性，但有些场景需要更细的粒度——比如部分符号在子模块内可见，对外不可见，而另一部分符号需要全局可见。
• 多语言混合构建：不同语言编译的目标文件无法合并为一个TU编译，但我们想把一组跨语言的符号打包成内部符号，避免与其他模块的符号冲突——比如C和汇编混合的子模块，通过嵌套链接合并后隐藏内部符号，只对外暴露接口。

内容来源于stack exchange