[tahoe-lafs-trac-stream] [pycryptopp] #62: builds which are intended to use the embedded copy of Crypto++ might get their headers from a system-supplied copy of Crypto++

pycryptopp trac at tahoe-lafs.org
Tue Jul 22 18:49:04 UTC 2014


#62: builds which are intended to use the embedded copy of Crypto++ might get
their headers from a system-supplied copy of Crypto++
--------------------------+------------------------
Reporter:  midnightmagic  |          Owner:
    Type:  defect         |         Status:  closed
Priority:  major          |      Milestone:
 Version:  0.5.19         |     Resolution:  fixed
Keywords:                 |  Launchpad Bug:
--------------------------+------------------------
Description changed by zooko:

Old description:

> As you can see here:
>
> http://tahoe-lafs.org/buildbot-
> pycryptopp/builders/MM%20netbsd5%20i386%20warp/builds/39/steps/test/logs/stdio
>
> ... it looks like with a system crypto++ installed (in my case, 5.6.1)
> there are pieces pulled in from the crypto++ 5.6.1 header files which
> reference a CryptoPP:: function which does not exist in the embedded
> version, which therefore causes the test to fail.
>
> The fix appears to be to tell (as I suspect you were going to anyway)
> setup.py to disable the embedded cryptopp stuff.

New description:

 As you can see here:

 [//buildbot-
 pycryptopp/builders/MM%20netbsd5%20i386%20warp/builds/39/steps/test/logs/stdio]

 ... it looks like with a system crypto++ installed (in my case, 5.6.1)
 there are pieces pulled in from the crypto++ 5.6.1 header files which
 reference a CryptoPP:: function which does not exist in the embedded
 version, which therefore causes the test to fail.

 The fix appears to be to tell (as I suspect you were going to anyway)
 setup.py to disable the embedded cryptopp stuff.

--

--
Ticket URL: <https://tahoe-lafs.org/trac/pycryptopp/ticket/62#comment:3>
pycryptopp <https://tahoe-lafs.org/trac/pycryptopp>



More information about the tahoe-lafs-trac-stream mailing list