第一件事是用ldd检查动态库自身依赖是否解析成功；若出现“not found”，可能因未加-fPIC或平台不匹配，若全部指向真实路径则结构基本正常。
直接用 ldd 查看依赖是否解析成功
生成 libxxx.so 后，第一件事不是跑程序，而是确认这个动态库本身能被系统识别。执行：ldd libmyhello.so
如果输出里出现 not found（比如 libc.so.6 => not found），说明编译时没加 -fPIC 或者目标平台不匹配；如果显示所有依赖都指向真实路径（如 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6），说明库文件结构基本正常。
用 gcc 链接测试程序但不运行
写一个简单 main.c 调用库中函数，然后只链接、不执行：gcc main.c -L. -lmyhello -o test_bin
若报错 undefined reference to 'xxx'，常见原因有：
• 函数声明没加 extern "C"（C++ 源码编译成 .so 时）
• hello.c 没导出符号（比如用了 static 修饰函数）
• -fPIC 漏了，导致 gcc -shared 实际生成的是无效位置相关代码
• 头文件没包含或函数名拼写不一致（注意大小写和下划线）
运行时报 ./test_bin: error while loading shared libraries
这是最常卡住的环节。错误信息末尾通常带具体库名，比如：libmyhello.so: cannot open shared object file: No such file or directory
这不代表库不存在，而是运行时找不到它。解决方式按优先级排列：
• 临时生效：运行前设 LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
• 永久生效（需 root）：把 libmyhello.so 拷到 /usr/lib 或 /lib，再执行 sudo ldconfig
• 更推荐：用 patchelf --set-rpath '$ORIGIN' test_bin（需安装 patchelf），让可执行文件自己带搜索路径
注意：sudo mv libmyhello.so /usr/lib 后必须 ldconfig，否则 ld 缓存不更新，依然报错
nm -D 和 objdump -T 看导出符号是否存在
如果链接通过但运行时函数调用崩溃或静默失败，很可能是符号没真正导出。执行：nm -D libmyhello.so | grep hello
或objdump -T libmyhello.so | grep hello
应看到类似 000000000000112a T hello 的输出（T 表示全局文本符号）。如果只有 U（undefined）或完全没结果，说明该函数未被编译进动态库——常见于：
• gcc -shared 时漏掉了对应 .o 文件
• 源文件里函数被条件编译宏屏蔽（如 #ifdef BUILD_SHARED 但没定义）
• 使用了隐藏属性（__attribute__((visibility("hidden")))）却没显式标记要导出的函数
libmyhello.so 文件存在，只要 ld 找不到它或符号表为空，整个链路就断在第一步。 
