本文介绍了如何避免由于运行环境存在动态库的多个版本而引发的各种问题，如崩溃等。
实际项目遇到了运行环境中崩溃的问题，但是在其它环境是正常的，下面进行问题分析：
1.崩溃栈信息
(gdb) bt
#0 0x00007f76899da13e in ?? () from /usr/lib64/libc.so.6
#1 0x000000000075e7cd in lh_insert ()
#2 0x000000000072ec27 in OBJ_NAME_add ()
#3 0x00007f7687cacc98 in ?? () from /usr/lib64/libssl.so.1.1
#4 0x00007f76898f1d68 in ?? () from /usr/lib64/libc.so.6
#5 0x00007f7687b7b229 in CRYPTO_THREAD_run_once () from /usr/lib64/libcrypto.so.1.1
#6 0x00007f7687cacee3 in OPENSSL_init_ssl () from /usr/lib64/libssl.so.1.1
#7 0x00007f768982e7b0 in ?? () from /usr/lib64/libcurl.so.4
#8 0x00007f76897df073 in ?? () from /usr/lib64/libcurl.so.4
................
观察以上信息，可以看出是libssl.so.1.1引起的崩溃。程序在其它环境运行正常，因此在确认代码基本没问题后，推断可能由于openssl库的问题引起。进一步看下堆栈，发现由于libcurl.so.4调用了openssl引发的崩溃。
2.确认openssl和curl版本
由于libssl.so和libcrypto.so是配套的，因此也需要看crypto
libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007fbb42ebe000)
libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007fbb42bd1000)
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007fbb44edb000)
正常环境崩溃程序依赖库：
libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007f1ca2afc000)
libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007f1ca2781000)
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f1ca494f000)
发现openssl版本不同。
3.统一openssl版本
尝试仅指定程序自己路径下的openssl动态库。方法为使用正常环境的openssl并用rpath指定，即在程序运行目录下创建./lib，并在编译时增加-Wl,-rpath=./lib/，同时将libssl.so.0.9.8和libcrypto.so.0.9.8拷贝到程序运行目录的./lib下。重新编译程序。
但不幸的是，程序依然崩溃。通过ldd查看可执行文件依赖库，发现仍然使用系统自带的/usr/lib64/libcurl.so.4，进而继续调用系统自带的/usr/lib64/libssl.so.1.1。
4.统一curl版本
继续将程序使用的curl指定为程序自己路径下的libcurl.so.4。将正常环境的libcurl.so.4拷贝到./lib。重新编译。
libssl.so.0.9.8 => ./lib/libssl.so.0.9.8 (0x00007f430876d000)
libcrypto.so.0.9.8 => ./lib/libcrypto.so.0.9.8 (0x00007f43083f2000)
libcurl.so.4 => ./lib/libcurl.so.4 (0x00007f430a5c4000)
通过ldd查看，程序已经使用了正常环境版本的openssl和curl库，运行程序不再崩溃。
5.总结
如果程序不指定具体某依赖库libXXX.so，会到系统目录中寻找，找到libXXX.so后，libXXX.so会继续在系统路径下寻找libXXX.so的依赖库。这时，即使程序指定了libXXX.so需要的依赖库也无效。解决办法是通过rpath指定程序自己的依赖库。同时，不需对系统做任何修改，不对运行环境产生任何影响。
另外，关于rpath的注意事项可参考本人另一篇文章《Linux so动态库路径搜索顺序》
