C程序调用Clang生成的.so或.dylib需满足三条件：符号必须显式导出（__attribute__((visibility("default")))并配extern "C"防修饰）、链接时用-L指定路径且库名符合libxxx.so/dylib规范、运行时通过LD_LIBRARY_PATH（Linux）或-Wl,-rpath,@loader_path（macOS）确保动态链接器可定位库。
Clang生成的.so或.dylib怎么被C程序链接调用
Clang生成的动态库（.so 或 .dylib）本身是标准 ELF/Mach-O 格式，C 程序完全能用，但必须满足三个硬性条件：符号导出可见、链接时能找到、运行时能加载。缺一不可。
为什么clang -shared编译后C程序仍报“undefined reference”
常见错误不是编译器问题，而是符号默认被隐藏。Clang/GCC 默认启用 -fvisibility=hidden，即使你写了 extern int my_func();，函数在动态库内部仍是 hidden 的，链接器看不到。
- 必须显式标记导出符号：Linux/macOS 上加
__attribute__((visibility("default"))) - 头文件中声明要和实现一致，例如：
extern __attribute__((visibility("default"))) int add(int, int); - C++ 项目还要包一层
extern "C"防名字修饰，否则 C 程序根本找不到符号名 - 不加
-fPIC编译目标文件会导致clang -shared失败或运行时报错relocation R_X86_64_32 against symbol
clang main.c -lmylib 为什么提示 cannot find -lmylib
链接器只在固定路径（如 /usr/lib、/usr/local/lib）找库，不会自动查当前目录。你得手动告诉它去哪找。
- 用
-L.指定当前目录为搜索路径：clang main.c -L. -lmylib -o main -
-lmylib对应的是文件名libmylib.so（Linux）或libmylib.dylib（macOS），命名不能错 - 如果库在子目录
./libs/，就写-L./libs -lmylib - Mac 上还需额外加
-Wl,-rpath,@loader_path/libs才能让可执行文件运行时找到 dylib
运行时报 error while loading shared libraries: libmylib.so: cannot open shared object file
链接成功 ≠ 运行成功。链接器只管编译期找库，运行时由系统动态链接器（ld-linux.so 或 dyld）负责加载，它有自己的路径规则。
- Linux：把
libmylib.so放到/usr/lib或/usr/local/lib，或临时设LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH - macOS：除了
-Wl,-rpath,@loader_path/...，还可用install_name_tool -change修改库的 install name - 最稳妥方式：把库和可执行文件放同一目录，Linux 加
export LD_LIBRARY_PATH=.，macOS 加-Wl,-rpath,@loader_path - 别依赖
./相对路径——运行时工作目录可能不是你预期的
真正卡住人的，往往不是编译命令写错，而是符号没导出、路径没配对、运行时环境没打通这三处。尤其 macOS 的 @loader_path 和 Linux 的 LD_LIBRARY_PATH 行为差异，容易漏掉其中一环。
