能否将动态库.so预链接至目标文件，提前绑定符号？

项目结构 #

./
 ├──libtardir/
 │   ├──include/
 │   │   └──...
 │   └──lib/
 │       └──libtar.so
 ├──check.c
 ├──main.c
 └──Makefile

现有编译逻辑 #

在check.c中通过#include <libtar.h>使用tar_open函数：

• 编译check.c为目标文件仅需指定头文件路径：$(CC) -I./libtardir/include -c check.c，此时传入-ltar -L./libtardir/lib会被忽略，因为这些是链接阶段专属参数。
• 生成可执行文件时才需要链接动态库：$(CC) -ltar -L./libtardir/lib check.o main.c -o main

核心需求 #

是否存在一种中间文件格式，能把动态库符号“预嵌入”到.o文件中，让如下Makefile生效？

check.o: check.c
    $(CC) -ltar -I./libtardir/include -L./libtardir/lib -c check.c

main: check.o
    $(CC) check.something main.c -o main

注：不考虑静态库方案，仍需保留libtar的rpath或LD_LIBRARY_PATH配置需求。

背景 #

项目涉及Nix、GHC与C++，Nix会对gcc和ld做特殊配置，但该配置未作用于GHC，若能实现上述操作可简化构建流程。

不存在这种能预嵌入动态库符号的.o变种文件，核心原因如下：

• 编译阶段（带-c参数）仅负责将源码翻译成机器码、生成目标文件，此阶段不会处理符号解析，-l和-L参数在编译时会被gcc直接忽略。
• 动态库的符号绑定要么是编译时静态绑定（属于静态库范畴，不符合需求），要么是运行时动态绑定，目标文件本身仅记录未解析的符号引用，不会提前关联动态库的路径或符号实体。

适配场景的替代方案 #

针对Nix+GHC的场景，可通过以下两种方式简化构建：

1. 生成链接描述文件

   • 正常编译check.o，再创建一个链接脚本check.ls，封装库的链接参数：

     INPUT(check.o -L./libtardir/lib -ltar)
     

   • 链接主程序时直接调用该脚本：

     main: check.o check.ls
         $(CC) -T check.ls main.c -o main
     

   这种方式把库的链接逻辑封装到脚本中，避免重复编写参数。

2. 将中间文件编译为共享库

   • 把check.c编译成带rpath配置的共享库作为中间文件，提前绑定libtar的依赖：

     check.so: check.c
         $(CC) -fPIC -shared -I./libtardir/include -L./libtardir/lib -ltar -Wl,-rpath=./libtardir/lib check.c -o check.so
     
     main: check.so
         $(CC) main.c check.so -o main
     

   • 此时check.so已包含libtar的依赖路径配置，链接主程序时直接引用即可，无需重复指定库参数。

两种方案均无需使用静态库，且保留了动态库的rpath配置需求，同时能适配Nix对gcc/ld的特殊配置，避免GHC处理复杂的链接参数。

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