Hi Zooko, > 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.... declspec(dllexport) is used to export variables, functions, and classes [1]. In C++, the functions are exported with mangled names, so they are usually accompanied by 'extern C'. (Also of interest might be 'Using dllimport and dllexport in C++ Classes' [2].)
Richter gives the subject a very nice treatment in 'Programming Application for Microsoft Windows' and its successor 'Windows via C/C++'. If the topic were covered by W. Richard Stevens, the Unix programming series would be a great reference. Unfortunately SO's were not around when the books were written. [1] http://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx [2] http://msdn.microsoft.com/en-us/library/81h27t8c.aspx On 5/24/09, Zooko Wilcox-O'Hearn <[email protected]> wrote: > > [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. -~----------~----~----~----~------~----~------~--~---
