[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