On Monday, 31 October 2016 22:39:39 UTC, Jeffrey Walton wrote: > > > Another workaround could be: (1) don't use libcryptopp.a, and (2) use >> >>> libcryptopp.so. >> >> >> Tried that. Didn't help. >> > > That's a drag. I thought you might be compiling against one vrsion, and > then runtime linking against another version. > > >> Can you get me remote access to that machine? >>> >> >> No. It does not belong to me, it belongs to my client. >> >> > > Can you bring me on as a subcontractor? >
I'd love to but I am pleased to report that there's no need - I have got it working! It turns out it was indeed a compiler bug in version 12.4. I suspected as much from the stack trace where it showed a string address was being misinterpreted as a this pointer, causing an error in a virtual function dispatch. After several calls to Rogue Wave support I eventually found out that in order to start using C++11 we would not only have to move from Source2016 to the fix release SourcePro2016.1, but we would also have to change compiler from 12.4 to 12.5. I just tried cryptopp 565 with 12.5 using the same compiler options that were used for the build of SourcePro12.5 and it worked. The benchmarks now complete successfully. > > Jeff > -- -- 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. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
