On Wed, May 27, 2009 at 12:20 PM, Niall Douglas <s_sourcefo...@nedprod.com> wrote: > > If it turns out that GCC is incapable of emitting the correct symbol > visibility declarations for a particular library, then an issue > should be filed with GCC's bugtracker. They have been most responsive > in the past with corner cases so I don't see it as an issue.
Thanks for the encouragement on that front. I'll keep in mind that gcc developers are responsive about these issues. That helps. > I am afraid I simply don't get this. Crypto++ seems to have a build > option for Windows as a DLL. If it does then it ports very easily > indeed to GCC symbol visibility. The only possible problem could be > if he used a lot of dllexported non-class based static variables > which you shouldn't in object orientatation. As Wei Dai explained in this thread: http://groups.google.com/group/cryptopp-users/browse_thread/thread/eb815f228db50380 He implemented the "CRYPTOPP_DLL" build of Crypto++ only because it was a requirement for FIPS validation, and it doesn't include a lot of the functionality of the library -- only that subset of the functionality which was being validated. Also, he attempted to port the same shared-lib build to Unix and failed and gave up. I don't know whether Crypto++ dllexports a lot of non-class-based static variables. It is a very big library with a big API and I don't have a good understanding of its scope. > If I'm reading between the lines here correctly, are you saying that > your libcrypto++ uses vX.XX of a libaes library but you want that to > interoperate which any other shared library which uses vY.YY of the > same libaes library? Obviously should APIs move out of step you get > all sorts of pernicious bugs. Wei Dai is the author of Crypto++, and I'm the author of pycryptopp. Pycryptopp is merely a few Python wrappers for certain Crypto++ features, plus a few small utilities that I need. The current build system of pycryptopp generates a module named aes.so, one named ecdsa.so, one named rsa.so and one named sha256.so. Each of these requires different functionality from Crypto++. The current build system links aes.so with the Crypto++ object files which are built from the Crypto++ .cpp files. This works, but it is not allowed to deploy as an official Debian or Fedora package when built like this. If I instead link aes.so with "-lcryptopp" and use the Debian- or Fedora- provided libcryptopp.so at load-time (using the default Python behavior of RTLD_LOCAL), it fails, because RTTI symbols are not merged at load-time, so an exception of type InvalidKeyLength, thrown from libcryptopp.so will not be caught by the handler in aes.so which attempts to catch exceptions of that type, because the RTTI symbol for InvalidKeyLength in libcryptopp.so has a different value than the RTTI symbol for InvalidKeyLength in aes.so. If I then set the RTLD_GLOBAL flag, then loading aes.so (which dynamically depends on libcryptopp.so) works, and the exception handler can catch exceptions of the specific type. But, if I then load both aes.so and rsa.so into the same Python interpreter, it seg faults. Here is the valgrind stack trace of that event: http://groups.google.com/group/cryptopp-users/attach/1a5553410c6976e5/crash.txt?part=2 So I am now engaged in refactoring pycryptopp so that instead of separate aes.so and rsa.so (and so on), there is instead a single _pycryptopp.so which provides all of the functionality, and then there is an aes.py and an rsa.py which import the appropriate names from _pycryptopp and leave out the other names. The problem with this strategy, I think, is that if someone were to load _pycryptopp.so using RTLD_GLOBAL, and then someone else were to load libcryptopp.so into the same Python interpreter, it would seg fault. But maybe nobody will ever want to do that. Thanks for you help! Regards, Zooko _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
