Build fails with older versions of gcc because the "generic" option for mtune switch is not supported. Reproducible: Always Steps to Reproduce: 1.emerge media-sound/phasex 2. 3. Actual Results: phasex.c:1: error: bad value (generic) for -mtune= switch engine.c:1: error: bad value (generic) for -mtune= switch make[2]: *** [phasex.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [engine.o] Error 1 make[2]: Leaving directory `/more/portage/tmp/portage/media-sound/phasex-0.12.0_beta3/work/phasex-0.12.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/more/portage/tmp/portage/media-sound/phasex-0.12.0_beta3/work/phasex-0.12.0' make: *** [all] Error 2 Shouldn't include the "generic" option automatically; that just tells (newer versions) of gcc to tune for current processors. This is Gentoo! - we like to add our own switches in /etc/make.conf, but thanks anyway. Please remove "-mtune" from future ebuilds, thank you.
Please attach emerge --info. It's not the ebuild that adds this option. Why not just use a newer gcc?
Created attachment 209263 [details] emerge --info
(In reply to comment #1) > Please attach emerge --info. It's not the ebuild that adds this option. Yeah, I realized that the problem is actually created upstream and I sent the author an email about it. > Why not just use a newer gcc? Several reasons: 1) No matter which version of gcc that I use, I *always* prefer to use my own optimization flags (unless, of course, they break something), that's why I use Gentoo in the first place. 2) Should I really have to upgrade gcc just for one app that tunes for generic (various "current" processor) features, especially since I'm using a Pentium III, which doesn't receive any of those benefits. 3) Upgrading gcc would also require pulling in a newer glibc; I just don't want to risk it, see reason #2 =) With open source software there is definitely a balance on the fine line of the LCD (lowest common denominator). Achieving that balance of optimization, library compatibility, and stability is an art - one that any software engineer should strive for. You have to think: Who is your audience? What is the likely range of their architecture? Is it really my responsibility to implement _____ feature? Less is more.
Aissigning to maintainer, since you are right that the package shouldn't do that. (In reply to comment #3) > (In reply to comment #1) > > Why not just use a newer gcc? > > Several reasons: > 1) No matter which version of gcc that I use, I *always* prefer to use my own > optimization flags (unless, of course, they break something), that's why I use > Gentoo in the first place. Of course. > 2) Should I really have to upgrade gcc just for one app that tunes for generic > (various "current" processor) features, especially since I'm using a Pentium > III, which doesn't receive any of those benefits. No, but you can't expect gentoo to support old compilers. This bug is an easy one, right. But what if the compiler would have segfaulted? There is a recent bug about gcc 3.4.6. What would you expect in this case? 4.1.2 is unmainted by upstream, as probably are older glibc releases. Software moves fast and on gentoo you shouldn't fall back too far or you might be lost. > With open source software there is definitely a balance on the fine line of the > LCD (lowest common denominator). Achieving that balance of optimization, > library compatibility, and stability is an art - one that any software engineer > should strive for. You have to think: Who is your audience? What is the > likely range of their architecture? Is it really my responsibility to > implement _____ feature? > > Less is more. > Well, one could say that anyone is expected to use at least the latest stable version. This way you have a good chance to have everyone using a consistent system.
I was able to work around this problem by adding: -mtune=pentium3 to my /etc/make.conf CFLAGS Replace 'pentium3' with your cpu if you are having the same problem (with any package). It overrides upstream 'generic' (or 'native') option. You can still have an '-march' options in your C[XX]FLAGS; it will take precedence over '-mtune'. > Well, one could say that anyone is expected to use at least the latest stable > version. If a core package is deemed stable at any point in time, and is given proper attention for bug/security fixes, then it usually works (even into the future, for the most part). As for the gcc 3.x reference, that is a major (not minor) update away from an issue like this, so I could understand the insistence of an upgrade. Since my problem is not related to a bug in gcc, but rather an unnecessary "feature" of phasex, I take the argument to be invalid in this context. I just really get annoyed by trivial issues like this one hampering compatibility. It reminds me of a particular software corporation. It would be nice to see a handful of programmers maintain (at least slightly) older software. For instance, it sucks that 100% of KDE developers moved to 4.x, effectively abandoning 3.5.x . It's like every time software finally gets to a stable/robust point, it's left out to dry and a new branch is created, with a whole new set of problems, and so on. I don't like to upgrade every 30 minutes. I just want something stable, that I can customize for my own needs. =)
