On Wed, 2010-11-17 at 15:21 -0500, Josh Boyer wrote: > On Wed, Nov 17, 2010 at 3:16 PM, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote: > > On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote: > > > >> This solution could be reverting the problem causing glibc change, or > >> maybe changing it to do forward memcpy's while still using the new SSE > >> instructions, or something more specific to the flash plugin, as long > >> as it will automatically fix things with a yum upgrade without requiring > >> any further user intervention. > >> > >> I would also like to point out that if this were to happen in Ubuntu > >> which we sometimes look at jealously for getting more attention / users > >> then us, the glibc change would likely be reverted immediately, as that > >> is the right thing to do from an end user pov. > >> > >> I've filed a ticket for FESCo to look into this, as I believe this > >> makes us look really bad, and the glibc maintainers do not seem to be > >> willing to fix it without some sort of intervention: > >> https://fedorahosted.org/fesco/ticket/501 > > > > Did anyone upstream look into a compatibility environment variable that > > could be exported to change the direction of the memcpy? Yes, it's a > > hack, but it would allow affected users to have an option. (of various pieces of software that they have installed, not just on Fedora - this will affect many different distributions and software) > > Alternatively, I agree that this is one case where a wrapper hack would > > also work for the flash plugin. I suspect, however, that other projects > > will be affected and so a generic solution would help. > > Other FOSS projects? That people can send patches to fix the broken > use of memcpy to? Seems the generic solution is exactly that. Well, it might be that the ideal is that all software everywhere is rebuilt, but there can be value in compatibility variables even for software for which source is available but not yet fixed. Jon. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
