运行时找不到libmyhello.so，因linux默认仅搜索/usr/lib、/lib等系统路径，不包含当前目录；解决方法包括：复制库至系统路径并sudo ldconfig，或临时设置ld_library_path=.运行，或永久配置该环境变量。
动态库编译成功但 ./a.out 报错 “./a.out: error while loading shared libraries”
这不是程序写错了，而是运行时找不到 libmyhello.so。Linux 默认只在 /usr/lib、/lib 等系统路径下搜索动态库，不会查当前目录。
常见错误现象：./hello: error while loading shared libraries: libmyhello.so: cannot open shared object file: No such file or directory
- 最直接的解决方式：把动态库复制到系统库路径（需 root 权限）
sudo cp libmyhello.so /usr/lib/sudo ldconfig（刷新动态库缓存） - 更安全、无需 root 的方式：用
LD_LIBRARY_PATH临时指定路径LD_LIBRARY_PATH=. ./hello
注意：.是当前目录，不能省略；等号前后不加空格 - 永久生效（仅限当前用户）：把
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$(pwd)"加到~/.bashrc末尾，然后source ~/.bashrc
gcc -lmyhello 链接成功，但运行时仍报找不到库
链接阶段（gcc -o hello main.c -L. -lmyhello）只检查符号是否存在，不验证运行时能否加载。也就是说，链接通过 ≠ 运行成功。
关键区别：
-
-L.只影响编译时链接器找库的位置，不影响运行时加载器 -
-lmyhello实际查找的是libmyhello.so（不是libmyhello.a），即使你同时放了.a和.so，gcc默认优先选.so - 可用
ldd hello查看可执行文件实际依赖哪些动态库，输出中某行显示not found就是问题所在
为什么加了 -fPIC 还是报错 “relocation R_X86_64_32 against `a local symbol’”
这个错误发生在你用普通 gcc -c hello.c 生成 hello.o 后，再试图用它生成动态库：gcc -shared -o libmyhello.so hello.o。
根本原因：hello.o 不是位置无关代码（PIC），而动态库必须由 PIC 目标文件构建。
- 正确做法：先用
gcc -c -fPIC hello.c生成hello.o，再gcc -shared -fPIC -o libmyhello.so hello.o -
-fPIC必须出现在编译.c → .o阶段，不能只加在-shared那一步 - 如果漏掉
-fPIC编译.o，后续任何-shared参数都救不回来
动态库更新后旧程序不生效？
Linux 运行时加载动态库是“按路径硬绑定”的，不是按文件名或时间戳。哪怕你替换了 /usr/lib/libmyhello.so，已启动的进程仍用旧版本内存映像；新启动的程序才会加载新版本。
但要注意：
- 如果用
LD_LIBRARY_PATH=.启动，改当前目录下的.so文件，下次启动就用新版本 - 用
sudo ldconfig刷新缓存后，/usr/lib下的库才真正“生效”给所有新进程 - 没有
ldconfig，有些系统可能缓存旧的库路径索引，导致新加的库找不到
最容易被忽略的是：ldd 看起来正常，./hello 却报错 —— 很可能是 libmyhello.so 自身还依赖别的库（比如它调用了 pthread 但没显式链接），这时得看 ldd libmyhello.so 而不只是 ldd hello。
