A fix to downgrade -march=pentium4 to -march=pentium3 for bug #4189 [ http://bugs.gentoo.org/show_bug.cgi?id=4189 ] actually does the opposite in xorg-x11-6.7.0-r1.ebuild and xorg-x11-6.7.0-r2.ebuild. The problem is that the ebuild maintainer (fairly reasonably) assumed that: replace-cpu-flags "pentium4" "pentium3" is equivalent to: replace-flag "-march=pentium4" "-march=pentium3" the only problem being that the args are: replace-flag <old> <new> and replace-cpu-flags <new> <old> which would confuse nearly anyone. This problem only affects emerges of xorg-x11-6.7.0-r[12] with gcc v3.(<=2).x. I understand that replace-cpu-flags was changed so it could be <new> <old> <old> <old> ... allowing multiple replacments at once but the change in the expected semantics would throw almost maintainer. Not very compliant with the principal of least surprise. What should really be done is to make replace-cpu-flags be repeated in the case of multiple substitutions. Why? Because we're not doing a recursive substitution on a bunch of files and would get a performance benefit from doing the substitutions all at once -- we're substituting in the environment variable CFLAGS!! Moreover, we'll never have that many substitutions anyways -- there simply aren't that many substitutable -march and -mcpu flags. Even if you're substituting every cpu down to a pentium, it's still not that bad. [ Sorry for the rant -- this just caused me a good half a day of crap. ] The fix: Make replace-cpu-flags (in flag-o-matic.eclass) behave like replace_flag (also in flag-o-matic.eclass), taking args of "<old> <new>" and update any ebuilds which use replace_cpu_flags in the old "proper way" to be fixed to the new "proper way". Ebuilds which use replace-cpu-flags "properly" and would need to be changed: bison/bison-1.875.ebuild egoboo/egoboo-2.22.ebuild flac/flac-1.1.0-r2.ebuild jpeg/jpeg-6b-r3.ebuild libpng/libpng-1.2.5-r7.ebuild libpng/libpng-1.2.5-r8.ebuild mysql/mysql-3.23.57-r1.ebuild mysql/mysql-3.23.58.ebuild perlmagick/perlmagick-5.5.7-r2.ebuild perlmagick/perlmagick-5.5.7.11.ebuild perlmagick/perlmagick-5.5.7.14.ebuild recode/recode-3.6-r1.ebuild rocksndiamonds/rocksndiamonds-3.0.8.ebuild rocksndiamonds/rocksndiamonds-3.1.0.ebuild Ebuilds which do not use replace-cpu-flags "properly" and would not need to be fixed after replace-cpu-flags is fixed: xorg-x11/xorg-x11-6.7.0-r1.ebuild xorg-x11/xorg-x11-6.7.0-r2.ebuild xorg-x11/xorg-x11-6.7.99.2.ebuild Reproducible: Always Steps to Reproduce: emerge xorg-x11-6.7.0-r[12] on a pentium III system (with -march=pentium3 set in CFLAGS) with gcc v3.[012].x as the compiler. Actual Results: Running X (xorg) crashes (coring if permitted) due to an offending illegal instruction. Expected Results: It should run, dangit!
I noticed this too while looking at the xorg-x11 ebuilds. Either flag-o-matic.eclass or the offending ebuild(s) need to be changed.
I've changed this for xorg-x11. Don't think gcc-porting is proper assignee of a function in flag-o-matic, reassigning to person who added replace-cpu-flags().
ebuilds/eclasses/documents should be all fixed now
