GCC动态库制作和调用完整教程

gcc -shared -fPIC 是生成 .so 的唯一正确组合：-fPIC 生成位置无关代码，-shared 指定共享对象格式，二者缺一不可；漏写 -fPIC 会导致链接失败，运行时库找不到需通过 LD_LIBRARY_PATH 或 -Wl,-rpath,'$ORIGIN' 解决。

gcc -shared -fPIC 是生成 .so 的唯一正确组合

要是直接用 gcc -shared 编译而不加 -fPIC ，在Linux系统下十有八九会遇到这样的报错：relocation R_X86_64_32 against `.rodata' can not be used when making a shared object。注意哦，这可不是什么警告，而是在链接阶段就会硬性失败的错误。

-fPIC 生成位置无关代码，这是动态库在内存任意地址加载的前提；-shared 告诉链接器输出共享对象格式。二者缺一不可，顺序无关，但必须同时出现。

• 错误写法：gcc -shared math_utils.c -o libmath.so（漏 -fPIC）
• 正确写法（一步到位）：gcc -fPIC -shared math_utils.c -o libmath.so
• 正确写法（分步更可控）：gcc -fPIC -c math_utils.c -o math_utils.o，再 gcc -shared math_utils.o -o libmath.so

链接时用 -L 和 -l，但运行时找不到库不是链接问题

编译能顺利通过，然而在运行时却报出 ./app: error while loading shared libraries: libmath.so: cannot open shared object file: No such file or directory 这样的错误，这表明链接过程是成功的，但是动态链接器在运行阶段压根就没有找到这个文件。

原因很直接：Linux 动态链接器（ld-linux.so）默认只查 /lib、/usr/lib 和 /usr/local/lib，不会看当前目录（.）。

• 临时解决（开发调试用）：export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH，再运行程序
• 推荐做法（部署用）：用 -Wl,-rpath,'$ORIGIN' 把运行时搜索路径硬编码进可执行文件，$ORIGIN 表示可执行文件所在目录
• 编译命令示例：gcc main.c -L. -lmath -Wl,-rpath,'$ORIGIN' -o app

头文件里不需要 __declspec(dllexport)，但 Windows 上必须加

Linux 的 .so 默认导出所有非 static 全局符号，只要函数不是 static，也不在匿名 namespace 里，就能被外部调用。所以 math_utils.h 里完全不用加任何导出宏。

但如果你写的是跨平台代码（比如同一套源码要编译成 Linux .so 和 Windows .dll），就得条件编译：

• Linux 下：#define API
• Windows 下：#define API __declspec(dllexport)
• 然后所有导出函数声明为 API int add(int, int);

否则 Windows 上 dll 会导出失败，导致 dlsym 或 GetProcAddress 返回 NULL。

libname.so 和 -lname 的命名规则容易对不上

你生成的文件叫 libmath_utils.so，但链接时不能写 -lmath_utils.so 或 -llibmath_utils，必须严格按规则来：

• -l 后面只写“名字部分”，去掉 lib 前缀和 .so 后缀
• libmath_utils.so → -lmath_utils
• libmy.so → -lmy
• libhello_world.so → -lhello_world

如果名字里有下划线或连字符，就老老实实照抄；别试图省略或改写。GCC 不做模糊匹配，错一个字符就报 cannot find -lxxx。

真正容易被忽略的是：-L 指定的路径必须包含 libxxx.so 文件本身，而不是它的符号链接（比如 libmath.so → libmath.so.1）。某些旧版系统在 -rpath 生效前，会先尝试加载符号链接指向的目标，但如果目标不存在或权限不对，也会静默失败。