Hide Forgot
Description of problem: CRYPTOPP_DISABLE_SSE2 is set for non x86_64 builds which causes entrypoints to be excluded from i686 builds that are still perfectly valid, specifically the *AlignedAllocate functions. Since SSE2 is valid for i686, application programmers should not be limited by this constraint. Since other distributions including Debian, OpenSUSE and Ubuntu do not disable SSE2 for i686 it's difficult to create cross-platform, cross-distro apps that include Fedora. Version-Release number of selected component (if applicable): 5.6.2 How reproducible: Always Steps to Reproduce: 1. Install both cryptopp.x86_64 and cryptopp.i686 2. readelf -a /usr/lib64/libcryptopp.so.6 | grep CryptoPP15Aligned 3. readelf -a /usr/lib/libcryptopp.so.6 | grep CryptoPP15Aligned Actual results: Step 2 will return matching entrypoints. Step 3 will not. Expected results: Both shared libraries should return entrypoints. Additional info: Delete or modify the cryptopp-x86-disable-sse2.patch file.
i686 builds in Fedora MUST NOT require SSE2. The same goes for Debian, by the way. If they really do not disable SSE2 in cryptopp, that's a bug in the Debian cryptopp package.
But according to http://www.cryptopp.com/ there is runtime detection: > x86, x86-64 (x64), MMX, and SSE2 assembly code for the most commonly used > algorithms, with run-time CPU feature detection and code selection so disabling SSE2 completely is probably NOT necessary.
(Summarizing my discussion with nucleo over IRC:) After looking at the code, I can confirm that the disable-sse2 patch is not necessary and should be dropped. The code correctly checks at runtime whether SSE2 is actually available.
cryptopp.i686 built without disable-sse2 patch will be binary incompatible, so all dependent packages should be rebuilt. I think this is task for Rawhide.
Yeah, unfortunately they're not compatible in either direction. I think only ceph depends on cryptopp.i686 though. Thanks for looking at this so quickly!
Dependent packages: ceph, pdns, pycryptopp, tegrarcm and amule from rpmfusion.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.