Having trouble building pycrytopp 0.5.29 on Debian

[Nick Murdoch-2]

Hi all,

I'm having trouble compiling pycryptopp 0.5.29 on a Debian sid box
with python2.5.

$ python setup.py build
running darcsver
setup.py darcsver: using extant version file ['pycryptopp/
_version.py', 'embeddedcryptopp/extraversion.h']
running build
running build_py
running egg_info
writing requirements to pycryptopp.egg-info/requires.txt
writing pycryptopp.egg-info/PKG-INFO
writing top-level names to pycryptopp.egg-info/top_level.txt
writing dependency_links to pycryptopp.egg-info/dependency_links.txt
reading manifest file 'pycryptopp.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pycryptopp.egg-info/SOURCES.txt'
running build_ext
building 'pycryptopp._pycryptopp' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -
Wstrict-prototypes -fPIC -I. -I/usr/include/python2.5 -c
embeddedcryptopp/cryptlib.cpp -o build/temp.linux-x86_64-2.5/
embeddedcryptopp/cryptlib.o -w
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid
for Ada/C/ObjC but not for C++ [enabled by default]
embeddedcryptopp/cryptlib.cpp:33:26: error: uninitialized const
‘CryptoPP::g_nullNameValuePairs’ [-fpermissive]
embeddedcryptopp/cryptlib.h:321:20: note: ‘const class
CryptoPP::NullNameValuePairs’ has no user-provided default constructor
error: command 'gcc' failed with exit status 1

GCC is version 4.6.1. Has anyone else had this trouble, or have any
suggestions on how to fix it?

Thanks,

Nick

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.

[zooko]

Hello Nick Murdoch:

Thanks for the bug report! I'm sorry it took me so long to get around
to replying.

I've opened a ticket to trac this issue in pycryptopp:

https://tahoe-lafs.org/trac/pycryptopp/ticket/77

Here's what the ticket says so far:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I. -I/usr/include/python2.7 -c
embeddedcryptopp/cryptlib.cpp -o
build/temp.linux-x86_64-2.7/embeddedcryptopp/cryptlib.o -w
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid
for Ada/C/ObjC but not for C++ [enabled by default]
embeddedcryptopp/cryptlib.cpp:33:26: error: uninitialized const
‘CryptoPP::g_nullNameValuePairs’ [-fpermissive]
embeddedcryptopp/cryptlib.h:321:20: note: ‘const class
CryptoPP::NullNameValuePairs’ has no user-provided default constructor

A little investigation makes me suspect that the reason this doesn't
happen on Crypto++ trunk is due to this patch:
http://bazaar.launchpad.net/~zooko/cryptopp/trunk/revision/466 . We
could adopt that patch (seems like a good idea anyway) or try a more
specific patch, such as the one suggested here:
 http://sourceforge.net/tracker/index.php?func=detail&aid=3285703&group_id=37892&atid=421366

--- src/crypto51/cryptlib.h.old 2011-04-12 14:50:28.000000000 +0200
+++ src/crypto51/cryptlib.h 2011-04-12 14:55:34.000000000 +0200
@@ -297,6 +297,7 @@
class NullNameValuePairs : public NameValuePairs
{
public:
+ NullNameValuePairs() : NameValuePairs() {}
bool GetVoidValue(const char *name, const std::type_info &valueType,
void *pValue) const {return false;}
};

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.

[zooko]

Oh my, this is probably not some simple, meaningless incompatibility
in a newer gcc release, it is probably a deep, confusing bug that has
bedeviled pycryptopp in the past, and that with Jeffrey Walton's help
[1], we *seemed* to have fixed, at least according to our buildbots,
but for some reason our test didn't stimulate the bug on most of the
buildslaves, only on Ubuntu [2].

Well, I just now figured out that this patch [3] is *probably* Wei
Dai's solution to the problem of double-free, and I should test out
that solution with our tests. I also saw a potential reason for why
the tests were effective on only one platform -- one of the test
modules didn't have a way to force the linker/loader to link it to
Crypto++.

Here are my notes on what I intend to do to investigate this issue:
[4]. Feel free to help. :-)

Keep in mind that there are two problems that we have:

1. Double-free: if two different libraries both linked to Crypto++
have been loaded then they may sometimes double-free the
g_nullNamedValuePairs (or possibly also an RNG object?)

2. Missed-exception: if an exception is thrown in one library and
caught in another then its type may not match (due to a failure of the
RTTI to be unified across libraries by the loader)

I suspect that toggling RTLD_GLOBAL can cure one of these problems
while triggering the other on some platforms.

Regards,

Zooko

[1] http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
[2] https://tahoe-lafs.org/trac/pycryptopp/ticket/44#comment:6
[3] http://bazaar.launchpad.net/~zooko/cryptopp/trunk/revision/466
[4] https://tahoe-lafs.org/trac/pycryptopp/ticket/44#comment:8

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscribe@....
More information about Crypto++ and this group is available at http://www.cryptopp.com.