直接链接需-L指定库路径、-l指定库名（去掉lib前缀和.so后缀），且-l必须在源文件后；运行时报错说明动态库路径未配置，可通过LD_LIBRARY_PATH临时设置或复制库至/usr/local/lib并执行sudo ldconfig永久生效。
直接链接就能用，但得确保运行时能找得到 libxxx.so 文件。光编译通过不等于能跑起来，这是最常卡住的地方。
编译时加 -L 和 -l 参数
这是链接阶段的硬性要求，缺一不可：
-
-L.告诉链接器去当前目录找库（替换成你的实际路径，比如-L./lib） -
-lmyhello表示要链接libmyhello.so—— 注意去掉lib前缀和.so后缀 - 顺序不能错：
gcc -o main main.c -L. -lmyhello，-l必须放在源文件之后 - 如果头文件不在默认路径，还得加
-I./include
运行时报 error while loading shared libraries
说明程序启动时找不到动态库，不是编译问题，是运行时环境问题：
- 默认只查
/usr/lib、/lib64等系统路径，不会看当前目录 - 临时解决：运行前执行
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH - 永久解决：把
libmyhello.so复制到/usr/local/lib，再运行sudo ldconfig - 验证是否生效：
ldd ./main输出里对应库那一行应该显示 “=> /path/to/libmyhello.so”，而不是 “not found”
gcc -shared -fPIC 编译动态库时的坑
这两个参数一个都不能少，否则链接或运行会失败：
-
-fPIC：生成位置无关代码，没它，gcc会报错 “relocation R_X86_64_32 againstxxxcan not be used when making a shared object” -
-shared：告诉gcc目标是动态库，漏掉它就生成普通可执行文件，后缀虽是.so但根本不是库 - 源文件必须先编译成
.o（用gcc -c），再用gcc -shared -fPIC -o libxxx.so xxx.o打包 - 别用
ar工具处理动态库 —— 它只管静态库.a文件
真正麻烦的不是编译命令本身，而是动态库路径管理。很多项目在开发机上跑得好好的，一放到新机器就崩，八成是 LD_LIBRARY_PATH 没设或者 ldconfig 没更新。动手前先 ldd 看一眼依赖，比反复试错快得多。
