[tahoe-dev] Fwd: that problem with comparing types across DLLs

[Zooko Wilcox-O'Hearn]

Folks:

We're trying to get pycryptopp to link against the system-provided  
libcryptopp.so on Debian and Fedora, as well as to not crash in  
mysterious ways some of the time.  Here is the most recent note that  
I sent about this issue to the cryptopp-users mailing list:

http://groups.google.com/group/cryptopp-users/browse_thread/thread/ 
eb815f228db50380

Regards,

Zooko


Begin forwarded message:

> From: Zooko Wilcox-O'Hearn <zooko at zooko.com>
> Date: May 23, 2009 21:03:29 PM MDT
> To: Zooko Wilcox-O'Hearn <zooko at zooko.com>
> Cc: Wei Dai <weidai at weidai.com>, "Crypto++ Users" <cryptopp- 
> users at googlegroups.com>
> Subject: Re: that problem with comparing types across DLLs
>
> Dear Wei Dai et al.:
>
> It is as I feared -- using the RTLD_GLOBAL flag for dlopen solves  
> the problem in question but leads to other problems.
>
> My project produces four different .so files, each of which is  
> built by including some of the .o files from Crypto++.  If I set  
> RTLD_GLOBAL then if more than one of these .so files is loaded into  
> the same process, the second and later ones to be loaded have  
> something messed up which quickly leads to a crash.  Attached is  
> the output of valgrind showing the details of one such crash.   
> (This is all 100% reproducible using the pycryptopp unit test suite.)
>
> What I really want is for there to exist some way in C++ that you  
> can express the following alternatives:
>
> 1.  For a given symbol, for example the type_info of an exception  
> class, then any code which #included that symbol, when loaded at  
> run-time, will get the same unique value so that throw and catch  
> and name-based arguments will work between any pair of DSOs.
>
> 2.  For other symbols, any code which #includes that code will get  
> its own separate address (symbol value) at run-time so that changes  
> made to the value stored in that address (symbol) by one DSO won't  
> affect other DSOs.
>
> I *think* that this is the intent of __declspec(dllexport) and its  
> brethren.
>
> However, not understanding how to make this work with g++, if it is  
> even possible, or if it is even a coherent thing to want, 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++.
>
> Oh, there's another alternative open to me -- make the pycryptopp  
> build system build a custom Crypto++ DSO (or maybe just the  
> standard Crypto++ DSO as specified by the Crypto++ GNUmakefile),  
> and then build four DSOs each of which dynamically links to that  
> shared DSO and continue to use RTLD_GLOBAL.  This is actually  
> already shown to work for our current unit test suite, but I don't  
> trust it because I don't understand why RTLD_GLOBAL causes these  
> crashes in other situations.
>
> Regards,
>
> Zooko
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash.txt
Url: http://allmydata.org/pipermail/tahoe-dev/attachments/20090523/5cec4033/attachment.txt 
-------------- next part --------------