[following-up to my own post] On May 23, 2009, at 21:03 PM, Zooko Wilcox-O'Hearn wrote:
> my next step is to declare that you can't have more than one DSO > which uses Crypto++ code in your process, so I'll refactor my > pycryptopp library to build all of the four features (AES, SHA256, > RSA, and ECDSA), as well as upcoming features (XSalsa20, Tiger) in > one DSO which is linked by including .o files from Crypto++. This > will work as long as nobody tries to use my DSO along with another > DSO which also uses Crypto++. This was imprecise. There are two known problems. One is if you do *not* turn on the RTLD_GLOBAL flag for dlopen(), and you try to pass a type_info between DSO's, such as by throwing an exception from libcryptopp.so and catching that exception in rsa.so, or such as by using the named-arguments feature. (I'm not sure precisely how that latter one results in type_info crossing a DSO boundary, but apparently it does.) This is the problem that Eric Hughes reported two and a half years ago [1] and that I started trying to solve a week ago [2]. The other is if you *do* turn on the RTLD_GLOBAL flag for dlopen(), and you try to load multiple DSOs which use symbols by the same name (because they each separately #included those symbols from Crypto++ header files), but which are supposed to be private to the DSO. This is the second sort of failure that I reported yesterday along with a stack trace from valgrind: [3]. So, if I go the first route, leaving RTLD_GLOBAL off and packing together all my crypto functionality into one DSO, then probably no harm will result because exceptions and named-arguments are not part of the API of my modules, therefore presumably nobody will ever try to catch exceptions thrown from my DSO. The sticking point here is that Debian and Fedora have a policy that any code which uses a library *must* be linked against the system- provided shared library. The Tahoe-LAFS project, if it is to be included in Debian and Fedora, is not allowed to build its own copy of Crypto++ internally -- it is required to re-use the system- provided shared library of Crypto++. Hm. I'm not sure, but I think that means I will have to implement *both* of these workarounds. I'll have to turn on RTLD_GLOBAL so that I can link against the system-provided libcryptopp.so on those two operating systems, and I'll also have to bundle my crypto code together into a single DSO in order to avoid the symbol collisions caused by turning on RTLD_GLOBAL. Sigh. I really feel like there must be a general solution to this. I suspect that the __cdecl(dllexport) machinery that is already baked into Crypto++ for building DSOs on Windows (DLLs) could probably be used to solve my problem if only I understood it better. See also http://gcc.gnu.org/wiki/Visibility . Thanks! Regards, Zooko [1] http://thread.gmane.org/gmane.comp.encryption.cryptopp/2305 [2] http://groups.google.com/group/cryptopp-users/browse_thread/ thread/eb815f228db50380 [3] http://groups.google.com/group/cryptopp-users/msg/1a5553410c6976e5 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
