Yeah, this is my second bug-catch tonight, and hopefully now, after 30~40 install-attempts I'm gonna get it correct without trashed wreckage instead of success... CFLAGS == CXXFLAGS, in this case, and notice that no other flags are declared. This is 1.4 rc3 gcc 3.2.2 ( I believe, anyways ) I don't know if /this/ one is a logic-bug or an architecture-bug. Requesting that a) the install-system ( bootstrap.sh, possibly "emerge system", as well ) be made to silence this flag, and b) the install-docs declare this blocker, and c) someone figure-out what, within the scripts, is killing results, and forward that info to whomever it is that develops the actually-broken program I'm /still/ running the Thunderbird w/ 512MB I was running earlier this morning ( and for the previous 3 years? )... still doing this again and again, changing different things in the make.conf to discover what's up...
Ok, so why don't you just do the sensible thing and set CFLAGS=CXXFLAGS="-march=athlon -O2 -pipe" ?
"Ok, so why don't you just do the sensible thing and set CFLAGS=CXXFLAGS="-march=athlon -O2 -pipe" ? ... -ftrapv This option generates traps for signed overflow on addition, subtraction, multiplication operations. ... I was trying to make a hard-minimum-limit for the integrity/breakproof-ness of my machine. if "sensible" doesn't include stopping stack-smashing, or buffer-overflowing, or phony-type-casting ( whatever that'd be called ), etc, why not just write viruses and call 'em apps? I was /trying/ to create a gentoo install that was both secure and optimized, and this setting is a security-setting, and it, all-by-itself, alone, slaughters the install, which means MAYBE some of the stuff compiled in the bootstrap.sh is SO overflow-filled, or otherwise screwy, that it can't be considered compilable, by GCC 3.2.2, with integrity-checking on, or... maybe GCC's screwed. WHICHEVER it is, it *causes one _to_see_* un-integrity in the underlying system(s) we all rely on, and instead of just hiding the problem, attacking /it/, rather than attacking-/awareness/of/-it, is sensible.
Sorry, I failed to communicate the /fundamental/ thing: that this bug wasn't documented, is /itself/ a bug. non-documentation means more damage gets created among users/sysadmins the reason I hammered at it, again and again, pinning down the bug(s) is to kill the surface-bug(s) of non-documentation. I'm not a developer, so it's up-to some other to kill the underlying bugs, but if I ignore, rather than kill, the surface-bug, then I'm helping it obliterate others' worth, and that is... ... against my 'religion'. /that/ is why I didn't simply choose 'safe' NON buffer-overflow-trapping settings and just ignore as means-of-happiness. sorry I didn't nail what I meant in me previous post.
you are correct on this. we should investigate why this happens, and document it at the very least.
sorry to sound cynical, but if you want to force things like that in the CFLAGS, I strongly urge to a) read the full documentation of EACH and EVERY source package in the bootstrap, and then do some googling on why it is a horrible idea to force something like this _globally_ and quite blindly onto your setup, as is the same for almost any single -f option that can be dreamed up or gleened from the gcc docs. Honestly, as sad as it sounds, I would really really love to push to lock down CFLAGS. They are the source of a lot of bugs that are not really bugs IMO. Maybe we should put a big disclaimer saying "if you edit these and b0rk your system don't say we didn't tell you so" and again sorry to sound a bit nasty, but please don't file any other bugs that say "this -f option broke my system". There is a fundimental reason why these projects set _their own_ cflags and honestly members of the bootstrap should not deviate from this (unless as I've said you read _all_ the appropriate docs for eacha nd every component to make sure you wont fail them). the -march options set a sensible (AND optimized) set of defaults for your arch and I would be more than happy to see them stay in more people's CFLAGS and not just have -f* on a whim cause the docs say it does something that they might like.
"if you want to force things like that in the CFLAGS, I strongly urge to a) read the full documentation of EACH and EVERY source package in the bootstrap, and then do some googling on why it is a horrible idea to force something like this _globally_ and quite blindly onto your setup" shoving this, on one, for using a flag that "generates traps for signed overflow on addition, subtraction, multiplication operations" .. makes little sense to me. Unlike the Marines, though, your answer isn't to explain why, but to order obedience. Fine. Buffer-overflows are a requirement. "I would really really love to push to lock down CFLAGS" .. so there is something fundamentally wrong with JUST STATING: 'these don't work during "bootstrap.sh" or "emerge system", and PROBABLY don't work in other conditions, you are given fair warning. Using these results in the following failure:' Or perhaps configurability, for others, is offensive? "don't file any other bugs that say 'this -f option broke my system'" Done. I'll not file ANY more bugs for any reason, for Gentoo, since it offends. Ever. "There is a fundimental reason why these projects set _their own_ cflags and honestly members of the bootstrap should not deviate from this (unless as I've said you read _all_ the appropriate docs for eacha nd every component to make sure you wont fail them)" I had asked that the harmful CFLAGS be suppressed within bootstrap.sh, and evidently that is impossible, monstrous, etc. User Must Obey Authority, Not Configure, And Shut The Fuck Up, is the proper Gentoo mode... "the -march options set a sensible (AND optimized) set of defaults for your arch and I would be more than happy to see them stay in more people's CFLAGS and not just have -f* on a whim cause the docs say it does something that they might like." Experimentation is something that a) resulted in Gentoo itself b) oft enough creates surprising results, and surprises are opportunities to either 1. gain some advantage, or 2. destroy some previously unknown/ignored damage/bug c) permits growing of autonomies, everywhere. ============ Remove me from bugs.gentoo.org, permanently, now ( since I cannot remove my name via the bugs.gentoo.org preferences system, and I'd report /that/ as a bug, but that would offend, obviously ). I don't want to ever participate in any sham values or charades. I _have_ removed all e-mail notices sent-to-me so I'll not ever know of any further correspondence on any bugs I'd submitted. I hope you live a very long time, and have everything you want. ( that is a curse, by the way ). Good bye.
if I upset you I'm sorry, and I _really_ do not appreciate how you have dealt with this on a personal matter here. I did not tell YOUnot to do this, I am saying that this sort of things happens regularly and that we should in fact lock it down, sheeeeesh. On a personal note, while it was nice of you to file this bug, it was also in very bad taste to swear and blame me as an autority figure and equate me to some sort of crazed miltary leader. That was a personal low blow and I will gladly endorse your request to leave bugs andgentoo if thats what you would like to do. Seemant: please remove me from release@gentoo.org, I care not for this any longer. Excuse the use of the language, but I really don't care to deal with this sort of lovely, and apparently well informed user any longer.
Mark, do not feel offended. Why do you think I reassigned this to release@gentoo.org in the first place ? ;/ The problem is that many people do not understand that gcc is still very buggy. Actually, if you want my *personal* opinion, gcc3 should still have been in an alpha stage. I have bitched for months about gcc3 when it came out, and how unstable it was before I jumped on the band wagon (do not know if anybody remembers). Second problem (and I think this is true for most part of the free software world), is that there is always a lack in *good* and *up to date* documentation. Thus the compiler/linker and features are not always used as it should be, resulting in difficult to track bugs. Thirdly, many things out there are coded by guys who never really studied the art of programming, and thus they do not know the first thing of good coding practice ... again resulting in all the overflow, etc bugs we have to live with every day. While this is not me saying free software suck (*g*), it is however my opinion that these with the environment we lay at the feet of the user with Gentoo, does tend to bring to front the worse of the problems in free software. I really wish there was a way to let people understand why it is that I use CFLAGS="-march=pentium3 -O2 -pipe", even though I do have a Pentium4 :( Same I guess with most Gentoo developers ... gcc3 just do not cut it if you start to add anything but the basic flags.
Az: Thanks for the note, but don't worry about me. I've given up preaching here and am walking far away from this stuff and going back to the rock I crawled from under. I give up trying to preach to the masses about things they don't wanna hear, it's a losing battle I'm tired of losing.
Mark Guertin: "it's a good thing you had not said what you said face to face ..., as the repercussions would have been rather grave." Murder me any day you want, Mr. Guertin. Any day you want. I again wish you to live long, and have everything you want, and I'll finish the sentence with saying: I hope my soul doesn't exist among 'the world' longer than necessary. Cheers, -me
> Please remove me from the release@gentoo.org list, I don't care to deal with > this sort of thing anymore. In fact if you wish you can remove my bugzilla > account as well, I've about had it with this sort of stuff. Mark, take it easy! ;^) Perhaps I don't know how often you have to deal with this sort of thing, but please don't let one <beep>'s comments make you think that your development efforts are not appreciated by many users and that your judgments are not respected. BTW, I agree with Mark's opinion that we should lock down the CFLAGS to some reasonable values (I've wanted to start this discussion for quite a while). By this I mean that we should not accept any bug reports that are caused by over-optimization or inserting some unstable GCC flags. IMO, we should still give the users the mechanism to break their system if they wish to, but establish a conservative set of CFLAGS combinations that we support. I'm extremely tired of taking all those bug reports with compilation breaking because somebody has -march=k* or programs crashing because of -ON (N>2). Over-optimization is a path to madness. I think that stripping CFLAGS in ebuilds is a conceptually wrong thing to do (in most cases). Sure enough, if you strip -march=k*, this will make the ebuild work for now. But perhaps in the next GCC (or package) release the -march flag will start working for that package. But who will be there reviewing those things? And how many lines of flag-stripping are we going to accumulate in the ebuilds before we decide that enough is enough? I propose that we only support the "-O -pipe" and "-O2 -pipe" settings in any combination with basic -mcpu/-march flags.
I want to express my opinions on this....I read this bug along with a few others over the last couple of days all pertaining to the same concept. I personally think Mark you said what alot of us feel but never say due to the repercussions that inevitably ensue. Although I don't want to discourage bug submission. The fact that CFLAGS over-optimization are generally the most common bugs we face every day says something to us, that something needs to change. Somehow we need to change the "because I can" attitude people have with CFLAGS. A flag like -ftrapv would be used in all builds if it worked the way the bug submitter thinks it to work. Wouldn't it be nice if a compile flag took care of stack smashing and buffer overflows etc all in one fell swoop. This bug is by far nothing new, and any user who wants to take bugs to a personal level with a dev really needs to look at himself. Us devs are volunteers who are here to help others out of courtesy and kindness with our knowledge and to the best of our abilities. From a managerial/development point of view everyone needs to realize that you "cannot please all the people all the time" it's a hard enough job just pleasing 1 person some of the time. Just take pride in knowing that you expressed yourself completely and tried to satisify as many as possible with 100% of your abilities and "keep on chuggin' away". With that said, I agree with some of you that CFLAGS need locked down, but only in the bootstrap and system stages. Bootstrap being hard locked and system being filtered like the testing gcc ebuild, but this is no immediate solution and should be a future endevour post 1.4. Until then a recommended CFLAGS and WARNINGS should be much more visibly present. If a user wants to over-optimize an ebuild and it breaks, so be it, but at least the bootstrap and system should still be up and stable, with as little of "big brothers's" help as possible. Just enough to make sure he/she doesn't burn himself.
One comment, one request. *Make the docs *SAY* that GCC 3.2.2 isn't stable, that ONLY -O, -O2, and -O2 -pipe and -Os -pipe work, and if one tries more than that then TRYING-IT is the bug, not any failure-of-its-working, and Please permit -Os as an optimization: I'm trying to build a 24MB RAM, 512MB disk machine for a friend, who can't afford more, and without being able to optimize for size, that option disappears for all who can't do LFS ( unless -Os is broke, too ). Many in the world can't afford enough /food/ let-alone dropping hundreds on a machine for living-in. I'd been trying to create a no-maintenance machine, immune to being trashed by buffer-overflows, etc. because it isn't going to have a sysadmin, it's going to have a normal someone. back ontopic.. If the ones who /know/ that these don't work, don't /directly/ communicate the information, via the instructions we are told to go by, then being angry at our using optimizations what ought make our ancient machines less .. dead slow .. is... ... ... Also, we ARE mistaken in our belief that the stable settings/choices ( as opposed to the ~arch settings ) choose actually-stable basis ( if GCC's scrambled ), but .. if this is already known, why not simply state it? From the book "Corps Business: the 30 Management Principles of the US Marines", which I wholeheartedly recommend to .. everyone, one of the principles is: Don't order someone to obey, for obedience, tell 'em the _essence_ of /what/ need be ( requirement ), and tell 'em /why/. --without that /why/ bit, it's simply opposing-groups opposing each other, and getting angrier: authoritarianism. Why do /that/? Mark's worth drastically more to Gentoo than me, though, and as I told Seemant, it isn't Mark I've problem with, it is only obliterative ?commitment or ?determination, ( english doesn't get-what-I-mean right ) it is the "obey!, freedom's not yours" authoritarianism religion what offended me, that assumes that experiment/inspiration need be obliterated to make reality be the way it /ought/ be ( engineering culture seems drenched with this ) I hope he reads the books in my .sig, which I recommend to everyone, ... why don't people get-it? /realize/ one's worth. As for me, though, I was right to ask to be removed from bugs.gentoo.org, but for the wrong reason. Remove me, please, from bugs.gentoo.org because my presence damages your group, or process, or order, and /that/ is obliterative of worth. I'm sorry I bothered/offended/unharmonized youse Live well ........ http://www.drawright.com/ - "The New Drawing on the Right Side of the Brain" ( Betty Edwards, check "Theory", "Gallery", and "Exercises" ) http://www.ldonline.org/ld_indepth/iep/seven_habits.html - "The 7 Habits of Highly Effective People" ( this site is same principles as Covey's book ) http://www.eiconsortium.org/research/ei_theory_performance.htm - "Working With Emotional Intelligence" ( Goleman: this link is /revised/ theory, "Working. . . " is practical ) http://www.leadershipnow.com/leadershop/1978-5.html - Corps Business: The 30 /Management Principles/ of the U.S. Marines ( David Freedman )
> *Make the docs *SAY* that GCC 3.2.2 isn't stable, that ONLY -O, -O2, and -O2 > -pipe and -Os -pipe work, and if one tries more than that then TRYING-IT is > the bug, not any failure-of-its-working, and It is a bit more involved. Out of all the gcc3 versions, gcc-3.2.2 is prob the best out of the lot. Problem though, is that it have so many new flags and targets (-march=...) that are not that properly tested, and breaks for some combinations of flags. The K6 arch had for instance a bad bug when using -Os. More to the fix (will be in portage soon) over here: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00508.html The 'pentium4' arch is badly broken for -msse2 and -mmmx2 optimizations. The 'athlon' arch for some reason also have problems. The 'athlon-xp' one seems the most stable. I am not sure if this is due to more gcc developers having Athlon XP processors ? The '-fomit-frame-pointer' is known to break some packages ... we have 'filtered' most of these cases if not all. > Also, we ARE mistaken in our belief that the stable settings/choices ( as > opposed to the ~arch settings ) choose actually-stable basis ( if GCC's > scrambled ), but .. if this is already known, why not simply state it? Because like I tried to say above, it is not clear cut, and above is only a few cases of problems. If we really needed to state all the issues that could be expected, it could be a few pages long. Using standard flags (-march=foo -O2 -pipe) is known to work most if not all of the time if there are no hardware issues. > Mark's worth drastically more to Gentoo than me, though, and as I told > Seemant, it isn't Mark I've problem with, it is only obliterative ?commitment > or ?determination, ( english doesn't get-what-I-mean right ) > it is the "obey!, freedom's not yours" authoritarianism religion what offended > me, that assumes that experiment/inspiration need be obliterated to make > reality be the way it /ought/ be ( engineering culture seems drenched with > this ) I think somewhere you two saw red, and did not read what the other are saying. The only place you could say he 'ordered' you, was: "and again sorry to sound a bit nasty, but please don't file any other bugs that say "this -f option broke my system". There is a fundimental reason why these projects set _their own_ cflags and honestly members of the bootstrap should not deviate from this (unless as I've said you read _all_ the appropriate docs for eacha nd every component to make sure you wont fail them)." And from that I get: 1) He did apologise if he might sound offensive 2) He did (as you above require) state the reason. 3) He did not say you could not still use the flags ("obey!, freedom's not yours" authoritarianism religion what offended me), but should know that if they cause issues, you should drop them and try without. > As for me, though, I was right to ask to be removed from bugs.gentoo.org, but > for the wrong reason. > > Remove me, please, from bugs.gentoo.org because my presence damages your > group, or process, or order, and /that/ is obliterative of worth. That I cannot do, and even if I could, I wonder if the stirer of the bee-hive should be given the luxury to go and hide in the house while others are at the mercy of the bees ... =)
for sake of completeness, here is the private letter which I sent (which was pasted out of context from). Don't bother to nuke your bugzilla account, I've left the project and you can happily call other on developers if you care to do so, and btw, it's a good thing you had not said what you said face to face when I was bascially AGREEING with you, as the repercussions would have been rather grave. My comment on the -f* optimizations was a very valid one, which seems to have set you off into some sort of twisted military mode of unkown origin. Now I suggest you go do some googling (I strongly suggest any mirrors of the libc-alpha list - which I've been a member of for 5+ years), and pay special attention to the discussions of gcc 3.2.2 (or whatever compiler it happened to be - which you couldn't even bother to identify, but decided filing a bug on would be fun anyway). Enjoy (or not) Gentoo, and you have yourself a lovely day. Gerk === I snapped a bit, and I apololgize, but I tried to be at least semi civil about this. I am very much taken aback by this persons wish for me to kill them and my apparent wish for them to snap into miltary obedience, and the way the entire situation is honestly handled by Gentoo as a whole. I won't go into rants about anythign here as it is not the time or the place, but suffice it to say that the considerable efforts I have put forth to date in order to try and make Gentoo the most advanced and best distro around, while trying to retain some sanity of functionality is over, and I think I will never be able to look at this project in the same way. I hope this gets resolved by the other gentoo developers and that this sort of thing can be avoided in the future for the project's sake. That being said, I won't be so around for this project any longer. This incident was just the icing on the cake for me and I am no longer willing to dedicate the level of comittment and time that I once had to the project. I'm also going to post this to our core mailing list as well. It's sad when things end up like this, but it seems this has been a forgone conlusion for me and was just a matter of time. Sadly it feels as a year's worth of my efforts to help push Gentoo towards some sort of reasonable QA process have truly been in vain (this may be a bit extreme but it's how I feel, and I'm sorry in advance if this offends anyone).
We've addressed this issue in the docs and by providing reasonable defaults, closing bug.
