Comment 256 for bug 727064

I agree it is complicated to support a different glibc from the one available upstream. In case of a 3rd party repo providing a parallel glibc, who is supposed to be responsible for updating it in case of new bug fixes? This is an endless work, which nobody will want to be responsible for.

In my opinion, for those not wanting to use the 32 bit version, the best fix is using a flash plugin that replaces memcpys for memmoves.

This is a no source rpm, which downloads the source from adobe and changes the binary:

http://people.atrpms.net/~pcavalcanti/srpms/flash-plugin-10.3-1.fc14.nosrc.rpm

I am more interested in this issue from a performance point of view than
from its effect on the flash plugin. If the new version is really slower that the previous one, well, then there is no excuse for not reverting the code.