macOS下GCC怎么生成动态库

在 macOS 环境里生成动态库，有几条规则基本绕不开：后缀必须用 .dylib，链接时要用 -dynamiclib，不能拿 -shared 直接替代；目标文件也得先用 -fPIC 编译好，再通过 -install_name 把路径指定为 @rpath，同时配合 -Wl,-rpath,. 让程序在运行时能正确找到库。少了其中任何一环，基本都会直接撞上 dyld: Library not loaded 这个报错。

macOS下用gcc生成动态库必须用.dylib后缀

macOS不认.so，强行生成libxxx.so会导致链接失败或运行时报“image not found”。系统只信任.dylib扩展名，这是硬性要求，不是可选项。

常见错误现象：ld: library not found for -lmylib 或运行时 dyld: Library not loaded，往往就是后缀写成了.so。

• gcc -shared 在 macOS 上不可用 —— 它会被忽略，实际调用的是 clang 的 linker，且不支持 -shared
• 必须用 -dynamiclib 替代 -shared
• 必须加 -fPIC（位置无关代码），否则报错 relocation R_X86_64_PC32 against symbol
• 输出文件名必须是 libxxx.dylib，比如 libhello.dylib

正确命令顺序：先编译.o，再生成.dylib

不能跳过中间的 .o 文件直接从 .c 生成 .dylib。macOS 的 linker 要求输入是目标文件，不是源码。

示例流程（假设 hello.c 提供 void hello(const char*)）：

• gcc -fPIC -c hello.c -o hello.o
• gcc -dynamiclib -o libhello.dylib hello.o

注意：-dynamiclib 是 macOS 特有 flag；Linux 下对应的是 -shared，二者不可混用。

链接时 -L 和 -l 顺序不能错，且需指定 install_name

就算已经成功生成了 libhello.dylib，直接执行 gcc main.c -L. -lhello 编译出来的可执行文件，运行时依然可能抛出 Library not loaded。原因并不复杂：macOS 通常会把动态库路径记录成绝对路径，比如 /usr/local/lib/libhello.dylib，但你机器上的这个库其实放在当前目录里，两边对不上，问题也就出现了。

解决方法是在生成 dylib 时就指定运行时查找路径：

• 用 -install_name 设置内部 ID：gcc -dynamiclib -install_name "@rpath/libhello.dylib" -o libhello.dylib hello.o
• 链接主程序时加 -Wl,-rpath,'$ORIGIN'（但 macOS 不支持 $ORIGIN）→ 改用 -Wl,-rpath,. 表示运行时从当前目录找
• 完整链接命令：gcc main.c -L. -lhello -Wl,-rpath,.

漏掉 -install_name 或 -rpath，哪怕编译成功，运行时也几乎必挂。

验证 dylib 是否可用：otool 和 dyldinfo

别靠“能编译”判断成功。用工具检查生成的 dylib 是否合法、路径是否可解析：

• otool -L libhello.dylib → 看输出里 @rpath/libhello.dylib 是否存在，而不是 /absolute/path/to/libhello.dylib
• otool -D libhello.dylib → 确认 install_name 值和你设定的一致
• dyldinfo -arch x86_64 -bind libhello.dylib（或 arm64）→ 检查符号绑定是否 clean

如果 otool -L 显示的是绝对路径，说明 -install_name 没生效，得重做；如果 dyldinfo 报 “no bind info”，可能是没导出符号（函数没加 __attribute__((visibility("default")))，尤其在加了 -fvisibility=hidden 的项目里）。