[C++-sig] errors with multiple loading cryptopp as shared lib on Linux

Zooko O'Whielacronx zookog at gmail.com
Thu Dec 10 19:15:10 CET 2009


[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


More information about the Cplusplus-sig mailing list