gcc -shared 时必须加 -fpic，否则因位置相关代码导致链接失败；动态库构建需所有 .o 文件用 -fpic 编译，再用 -shared 打包，且 ldflags 必须置于命令末尾。

gcc -shared 时必须加 -fPIC

不加 -fPIC 编译出来的目标文件无法被正确打包进动态库，链接时会报错：relocation R_X86_64_32 against `xxx' can not be used when making a shared object。这是因为动态库在加载时需支持地址无关，而默认编译生成的是位置相关代码。

正确做法是：所有参与动态库构建的 .c 文件，都必须先用 -fPIC 编译成 .o，再用 -shared 打包：

• gcc -fPIC -c foo.c -o foo.o
• gcc -fPIC -c bar.c -o bar.o
• gcc -shared -o libmy.so foo.o bar.o

链接静态第三方库（.a）到动态库里

如果你要把一个静态库（比如 libthird.a）的内容“塞进”你的动态库，而不是让调用者去额外链接它，就得显式把 .a 文件当作输入对象传给 gcc -shared：

• 不能只写 -lthird —— 这会让链接器去找 libthird.so，不是你要的效果
• 必须用绝对或相对路径直接引用 libthird.a：gcc -shared -o libmy.so my.o /path/to/libthird.a
• 如果 libthird.a 本身依赖其他库（比如 libm.a），这些依赖也得一并列在命令末尾，顺序不能颠倒（依赖项靠后）

注意：这样打包后，libmy.so 就不再需要调用方提供 libthird.a 对应的符号，但它体积会变大，且失去第三方库单独升级的能力。

ZFCC工期索赔.海合会实务(SCL+GCC)

基于SCL准则与海合会国家法规的对比分析，提供海合会地区工程工期索赔的专业指导，覆盖SCL协议适用、伊斯兰法影响、本地法律要求等核心内容。

下载

链接动态第三方库（.so）到你的动态库

这是更常见的情形——你的动态库只是“用”了别人家的 .so，不打包进去，只声明依赖。这时 -lxxx 和 -L/path 是有效的，但要注意两点：

• 链接阶段必须能定位到 libxxx.so（否则报 cannot find -lxxx），所以 -L 路径要真实存在且含该文件
• 运行时，系统仍需找到该 .so；若不在 /usr/lib 或 /lib，就得靠 LD_LIBRARY_PATH 或 /etc/ld.so.conf.d/ 注册
• 可以用 readelf -d libmy.so | grep NEEDED 验证是否成功记录了依赖项，例如输出含 libxxx.so

Makefile 里容易漏掉的 -fPIC 和 LDFLAGS 顺序

写 Makefile 构建动态库时，常见错误是把 -fPIC 只加在最终 gcc -shared 命令里，而没加在 .o 编译步骤中。结果是 .o 不含位置无关码，-shared 必然失败。

另一个坑是 LDFLAGS 放错位置：必须出现在 gcc -shared ... $(LDFLAGS) 的末尾，否则像 -lxxx 这类选项可能被忽略。CMake 中同理，target_link_libraries() 必须放在 add_library(... SHARED) 之后，且目标名大小写完全一致。

真正麻烦的从来不是“怎么写命令”，而是确认每个中间文件（.o）、每个依赖库（.a/.so）、每个环境变量（LD_LIBRARY_PATH）和每个路径（-L/-I）是否都对得上号——少一个环节，undefined symbol 或 cannot open shared object file 就立刻出现。