amule 2.0.0-rc6 (and later) includes its own slimmed version of crypto++. it has the same bug as those: http://bugs.gentoo.org/show_bug.cgi?id=63922 http://bugs.gentoo.org/show_bug.cgi?id=64646 the fix is to add -mno-sse2 to CFLAGS. but shouldn't we disable the internal version of crypto++ and make it use crypto++ from portage?
Created attachment 42026 [details, diff] Removes P4 specific optimizations. Yes, the P4 optimizations have caused quite some problems, and we have removed those specific optimizations from the source, so it shouldn't be a problem when rc7 is released. I've attached the patch I used, in case you are interested.
Created attachment 42035 [details, diff] Removes P4 specific optimizations. Hm, sorry, I accidentally posted (and committed =/) the wrong diff, which removed _all_ P4 optimizations rather than just SSE2 optimizations. I've uploaded the corrected patch.
While we're at it, why don't we just disable using of embedded crypto++ and use the global one by specifying --disable-embedded_crypto to amule?
*** Bug 65413 has been marked as a duplicate of this bug. ***
-mno-sse2 is not recognized for archs diffrent than x86 and makes crypto++ to fail compilaton for example on PowerPC. It should be filtered only for platforms that supports this switch.
amule-2.0.3-r1 uses external crypto++. thanks for reporting
But there seems to be no dependency to crypto++!
why use the unneeded external crypto++?
hummm, :/ I still have this crypto++ problem with amule-2.0.3.ebuild (only "stable" version on amd64). One can find in that ebuild an econf specifying: --disable-embedded-crypto no wonder he then asks for the external crypto++ lib. Either remove this econf option, or add a dependency, or talk to me please :)
