[tahoe-lafs-trac-stream] [pycryptopp] #77: compile failure error: uninitialized const ‘CryptoPP::g_nullNameValuePairs’ [-fpermissive]

[pycryptopp]

#77: compile failure error: uninitialized const ‘CryptoPP::g_nullNameValuePairs’
[-fpermissive]
------------------------+-----------------
     Reporter:  zooko   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  major   |  Milestone:
      Version:  0.5.29  |   Keywords:
Launchpad Bug:          |
------------------------+-----------------
 {{{
 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;}
 };
 }}}

-- 
Ticket URL: <http://tahoe-lafs.org/trac/pycryptopp/ticket/77>
pycryptopp <https://tahoe-lafs.org/trac/pycryptopp>