Ok, looks like the solution was to rebuild cryptopp itself with visibility 
flags. Which makes sense in retrospect...

This is how my CXXFLAGS look like now:
CXXFLAGS += -arch x86_64 -arch i386 -fvisibility=hidden 
-fvisibility-inlines-hidden

On Monday, July 16, 2012 4:03:37 PM UTC-6, Eugene Zolenko wrote:
>
> Hi, 
>
> I'm using cryptopp 5.6.1 on OSX and statically link it to *both* main app 
> and a framework it links to (for different purposes). Both binaries use 
> -fvisibility=hidden and -fvisibility-inlines-hidden (
> http://gcc.gnu.org/wiki/Visibility) on GCC 4.2 and cryptopp is built 
> normally with the makefile.
>
> Everything is fine until the point where I use some random number 
> generator in my framework and die horribly by std::terminate. This is the 
> exception it prints:
>
> NameValuePairs: type mismatch for 'RandomNumberGeneratorPointer', stored 
> 'PN8CryptoPP21RandomNumberGeneratorE', trying to retrieve 
> 'PN8CryptoPP21RandomNumberGeneratorE'
>
> Looks like I'm hitting the typeinfo problem across shared object 
> boundaries: http://gcc.gnu.org/faq.html#dso
>
> We managed to build cryptopp as a dylib framework of its own, but that 
> didn't help much: same crash, same stack but different modules involved 
> (before it was framework/app/crash, now it is 
> framework/cryptopp.framework/crash).
>
> I suspect some templates are instantiated in both binaries and confuse 
> each other on runtime.
>
> Is this a supported scenario at all? I looked around for a define I can 
> use to make it magically go away, but best solution so far is to modify 
> NameValuePairs type comparison function to compare strings instead of using 
> operator== (that's what happens when built with MS compiler anyway...).
>
> Did anybody encounter that? I don't want to rename cryptopp namespace and 
> have 2 copies of the lib... (because this kind of stuff never stops at 2...)
>
> Here is the actual crash. Notice how the whole chain happens in *framework
> * and GetRequiredParameter is called from out of *app.*
>
> 6 libc++abi.dylib 0x94cf3268 std::terminate() + 23
> 7 libc++abi.dylib 0x94cf42a0 __cxa_throw + 112
> 8 *app* 0x00d38d2b CryptoPP::NameValuePairs::ThrowIfTypeMismatch(char 
> const*, std::type_info const&, std::type_info const&) + 155 (cryptlib.h:291)
> 9 *framework* 0x04dd0149 
> CryptoPP::AlgorithmParametersTemplate<CryptoPP::RandomNumberGenerator*>::AssignValue(char
>  
> const*, std::type_info const&, void*) const + 109
> 10 *framework* 0x04de9359 
> CryptoPP::AlgorithmParametersBase::GetVoidValue(char const*, std::type_info 
> const&, void*) const + 457
> 11 *framework* 0x04de9326 
> CryptoPP::AlgorithmParametersBase::GetVoidValue(char const*, std::type_info 
> const&, void*) const + 406
> 12 *framework* 0x04de940f 
> CryptoPP::AlgorithmParameters::GetVoidValue(char const*, std::type_info 
> const&, void*) const + 47
> 13 *app* 0x00d7b30a void 
> CryptoPP::NameValuePairs::GetRequiredParameter<CryptoPP::RandomNumberGenerator*>(char
>  
> const*, char const*, CryptoPP::RandomNumberGenerator*&) const + 58 
> (cryptlib.h:296)
> 14 *framework* 0x04e60148 
> CryptoPP::RandomNumberStore::StoreInitialize(CryptoPP::NameValuePairs 
> const&) + 56
> 15 *framework* 0x04db61ae CryptoPP::Source::SourceInitialize(bool, 
> CryptoPP::NameValuePairs const&) + 34
> 16 *framework* 0x04dcfd6d 
> CryptoPP::RandomNumberSource::RandomNumberSource(CryptoPP::RandomNumberGenerator&,
>  
> int, bool, CryptoPP::BufferedTransformation*) + 167
>
> Thanks
>

-- 
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.

Reply via email to