[cross-posted to the Crypto++ users mailing list and the Python C++-sig.] David wrote on the Crypto++ users mailing list:
We experience errors when trying to use cryptopp as shared lib from more than one other shared libs.
I struggled with this for a long time for the pycryptopp project and finally gave up and just refactored pycryptopp so that there is only one sharedlib that links to libcryptopp.so. It kind of sucks because this means that if some *other* library gets loaded into the same process as pycryptopp and that library links to libcryptopp.so then it will crash the process. But, I couldn't figure out any other way to solve it. Here is a letter I wrote at the time outlining four possible solutions. I tried them all and ended up using the one listed as "#2": http://mail.python.org/pipermail/cplusplus-sig/2009-May/014531.html I still kind of hope that some Crypto++ or Python hackers will figure out how to implement the one listed as "#4", which is to mark the appropriate symbols in the Crypto++ API as being satisfied by a different DSO (mark them as 'U' -- undefined symbols) so that the loader will do the right thing. See the end of that letter referenced above for details. It kind of seems like gcc cannot be configured to do the right thing here, although MSVC can. Here is an earlier letter I wrote explaining how there are two different problems, one that happens if you set RTLD_GLOBAL and one that happens if you don't set RTLD_GLOBAL: http://groups.google.com/group/cryptopp-users/msg/7a0dacd0a4be5e2d Here is the ticket that we used to track this issue in pycryptopp until it was solved by the "there can be only one user of libcryptopp.so" solution: http://allmydata.org/trac/pycryptopp/ticket/9 Regards, Zooko