The "/usr/portage/dev-libs/libmcrypt/libmcrypt-2.5.1-r4.ebuild" file contains a few things that strike me as odd, thus I'd humbly request to reconsider those decisions. Here're my comments: - An -m(cpu|arch)=k6 CFLAG setting, possibly set by /etc/make.conf, is stripped with reference to "modules/algorithms/gosh.c". (Please note that the file is called "gost.c", not "gosh.c".), which defines an array called "k6". I don't see why that would be problem? The pre-processor symbols defined by gcc when compiling with "-march=k6" are called "__k6" and "__k6__", so this shouldn't be a problem. - The ebuild files disable thread support in the library, referring to the PHP manual. I think this decision is unfortunate, because this make the library unusable (sort of) in multi-threaded applications. libmcrypt even describes how to provide mutex-locking functions in order to work in a multi-threaded application, so if PHP has problem with that, it surely is a bug in PHP and should be fixed there. Disabling thread-support altogether strikes me as overkill. In fact, I even doubt that it achieves anything, because libmcrypt doesn't do anything with threads internally. The requirement for synchronization comes from the fact that it uses dlopen() to load modules when started, so disabling threads will probably not even help if there are any problems with PHP. - Finally, it would be very nice if the ebuild process would fetch the contributed algorithms like IDEA as well. They are available from: ftp://mcrypt.hellug.gr/pub/crypto/mcrypt/libmcrypt/modules/ Maybe some USE setting would be in order to control this, but my guess is that just installing those modules is fine and doesn't do any harm at all.
Please look at: http://bugs.gentoo.org/show_bug.cgi?id=2276 and comment again. If this is fixed for 2.5.1, sure, but else, it was too much hassle/effort to try and resolve *again*.
