gcc -shared -fpic 是生成 .so 的唯一正确组合：-fpic 生成位置无关代码，-shared 指定共享对象格式，二者缺一不可；漏写 -fpic 会导致链接失败，运行时库找不到需通过 ld_library_path 或 -wl,-rpath,'$origin' 解决。
gcc -shared -fPIC 是生成 .so 的唯一正确组合
不加 -fPIC 直接用 gcc -shared 编译，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 生效前，会先尝试加载符号链接指向的目标，但如果目标不存在或权限不对，也会静默失败。
