Pascal BERTIN posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 12 Apr 2005 10:17:52 +0200:
[yuck, upside downposting, anyway, it's about KDE and -Os] > in fact I've just had a look at what is compiled, and -O2 is added > BEFORE allready configured CFLAGS, as gcc man pages states that the last > optimization level will be used, wouldn't changing configure to add -O2 > at the end of CFLAGS fix this potential break ? In general, portage's logic is set up to place the user CFLAGS after any default eflags. However, where necessary, ebuilds can change the user's CFLAGS as needed before that is done. Take a look at the flagomatic eclass to see the collection of helper functions designed to make that quite easy. As for KDE and -Os, I've had absolutely no issues with it here, and KDE is my desktop environment of choice, so either it's in some obscure stuff I don't compile (all of kdeedu, for instance, or koffice), or the ebuilds have already been set up to fix it (altho I've not seen such, and where I've looked, -Os still continues to occur last in the string as it's in my CFLAGs), or it only happens with some combination of related CFLAGS I don't use, or as the technotes say, it applied to KDE 3.2-something, back before GCC 3.4, and doesn't apply to the newer stuff. Besides, -Os /shouldn't/ create issues, as the only stuff activated by any of the -Ox options are known to be generally safe, or they wouldn't be activated at least on that arch, for a -Ox option, in the first place. The GCC devs don't put the dangerous stuff in the -Ox options, you must enable it with specific flags. Further, it's pretty much -O2, minus the size-expanding stuff like unrolling loops and the like in the first place, so if -O2 works, so /should/ -Os. At least that's the theory. Of course, as complicated as compiling to machine code can be, there are ways to break virtually anything if one is trying to do so, or using known dangerous techniques. Still, I've seen no evidence of such in regard to -Os in KDE 3.3 or 3.4, at least as compiled with GCC 3.4.x. Personally, what I think happened was the interplay of -funit-at-a-time, which shouldn't be dangerous because it doesn't enable any new functions, only enables optimization at the entire unit scope level, which wasn't done before it was introduced in GCC 3.4 (and backported to some 3.3 versions, particularly the hammer compatible ones), with bugs in the code that were never caught before, because GCC wasn't optimizing over the whole scope of the code unit. That interplay exposed existing bugs in the code, with the result being that -Os, which enables -funit-at-a-time, was considered a riskier proposition than it should have been, for a time. However, people correctly filed bugs on on such code, where it would compile without -funit-at-a-time but not with it, and in any reasonably maintained project, such bugs should have been worked out well before now. Again, the technotes mention KDE-3.2, which was current with gcc-3.3, and -funit-at-a-time was very new at that point and still exposing bugs, probably including at least one in KDE. By the time gcc-3.4 went ~amd64, however, and by KDE-3.3.2 or 3.3.3 anyway, those bugs appear from my experience anyway to have been ironed out, and I've had no compiling issues whatsoever with -Os or -funit-at-a-time. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
