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 的，链接器看不到。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 必须显式标记导出符号：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</H3>
<p>链接成功 ≠ 运行成功。链接器只管编译期找库，运行时由系统动态链接器（<code>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 行为差异，容易漏掉其中一环。