你的问题核心在于libB.so引用的AWS符号DefaultResponseStreamFactoryMethod未被正确解析，导致dlopen加载libA.so时触发"undefined symbol"错误。下面一步步拆解分析并给出解决方案：

1. 确认libB.so中目标符号的状态 #

先搞清楚这个符号在libB.so里是已定义还是未定义：

nm -gD /usr/local/lib/libB.so | grep _ZN3Aws5Utils6Stream34DefaultResponseStreamFactoryMethodEv

如果输出开头是U，说明这个符号在libB.so中是未定义状态——也就是说编译libB.so时，你没有链接提供该符号的AWS核心库（比如libaws-cpp-sdk-core.so）。

2. 检查libB.so的依赖链 #

运行命令查看libB.so的依赖列表：

ldd /usr/local/lib/libB.so

如果列表里看不到AWS相关的库（比如libaws-cpp-sdk-core.so），这就是问题根源：libB.so编译时没有把依赖的AWS库链接进去，导致它自己都找不到这个符号。

3. 重新编译链接libB.so #

修改libB.so的编译命令，确保链接AWS的核心库（具体库名根据你的AWS SDK版本调整），并且注意链接顺序（依赖库要放在源码/目标文件之后）：

g++ -fPIC -shared -o libB.so b1.o b2.o -laws-cpp-sdk-core -laws-cpp-sdk-s3

如果AWS库不在系统默认搜索路径，还要加上rpath参数让libB.so能定位到它们：

g++ -fPIC -shared -o libB.so b1.o b2.o -laws-cpp-sdk-core -laws-cpp-sdk-s3 -Wl,-rpath=/usr/local/lib/aws-libs

编译完成后，再用ldd和nm确认依赖和符号状态是否正常。

4. 调整dlopen的调用参数（权宜之计） #

如果暂时无法重新编译libB.so，可以尝试修改dlopen的调用标志，用RTLD_GLOBAL让加载的库符号全局可见：

void* handle = dlopen("/usr/share/orthanc/plugins/libA.so", RTLD_NOW | RTLD_GLOBAL);

不过这种方式可能引发全局符号冲突，仅作为临时 workaround，优先推荐修复libB.so的编译链接问题。

5. 验证系统库搜索路径 #

最后确保AWS相关库在系统动态链接器的搜索范围内：

• 可以将AWS库路径添加到/etc/ld.so.conf.d/aws.conf，然后运行ldconfig更新缓存。
• 或者临时设置环境变量：

export LD_LIBRARY_PATH=/usr/local/lib/aws-libs:$LD_LIBRARY_PATH

内容的提问来源于stack exchange，提问作者rodrigo