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.ogcc -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），而你本地的库在当前目录。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
解决方法是在生成 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 的项目里）。
