Extreme CFLAGS problems...

Message

ciaranm · Post by **ciaranm** » Wed Dec 22, 2004 7:08 pm

lightvhawk0 wrote:I just wish there was a switch so I could turn it on or off, also with cflag filtering off I'd like to have a warinig displaying known bad cflags so I could know when it breaks what cflags to remove.

Flags that're safe, to the extent that we'll definitely filter them if we find that they break anything: -O2 -m{arch,cpu,tune}=whatever (arch dependent). On x86 you can add in -fomit-frame-pointer. On sparc you can add in -frename-registers. -pipe is safe too, of course.

mcspiff · Post by **mcspiff** » Wed Dec 22, 2004 10:22 pm

My post was intended to be read with just a hint of sarcasm, which probably wasnt obvious. Its not that i dont understand why some people want to drop cflags filtering and just let whatever happen during the compile happen. Believe me, i feel the ricers are killing gentoo more than SCO or microsoft ever could hope. But sadly just letting them shoot themselves in the foot just isnt good systems design. Id hate to fuel the anti-gentoo fires by intentially breaking portage.

So why not inform the user that they are nuts, and disable compileing with those flags. Have this behivor be controlled by a setting in make.conf (or somewhere more hidden

)

ciaranm · Post by **ciaranm** » Wed Dec 22, 2004 10:27 pm

mcspiff wrote:So why not inform the user that they are nuts, and disable compileing with those flags. Have this behivor be controlled by a setting in make.conf (or somewhere more hidden )

Because then we get massive hissy fits from the ricers, as can be seen earlier in this thread.

mcspiff · Post by **mcspiff** » Wed Dec 22, 2004 10:27 pm

And dropping Cflags filtering wont get said hissy fight?

Lokheed · Post by **Lokheed** » Wed Dec 22, 2004 10:36 pm

mcspiff wrote:So why not inform the user that they are nuts, and disable compileing with those flags. Have this behivor be controlled by a setting in make.conf (or somewhere more hidden )

Because I dont want hidden options...this isnt Windows where you have to hide things from users. I am a mature adult who makes logical decisions and does research and there are more of us then there are of "them". So I dont see why we should get punished because some ricer has a 4 page CFLAGS and does nothing but file stupid bug reports and prance around telling newbies how fast his system is which perpetuates the cycle...

You cant inform those that dont want to be informed. These ricers are the way they are because they dont read and they dont research. How are you going to inform them I wonder? Smoke signals? The entire point of this is ricers dont bother reading warning or take any advice into consideration. Look at the orginator of the thread. His replies still suggest he isnt going to trim down his CFLAGS despite being warned by what, 80% of the people in this thread? They dont listen and thats why they are where they are...

You talk about coddling a user, then hiding settings that disable CFLAGS? I doubt anyone is going to complain for dropping CFLAGS that are known to break 99% of the packages out there. I am sure the developers will be happy, the programmers wont mind dealing with less faulty bug reports and Gentoo starts to save face...

If the ricers complain they are met with a barrage of profanities as 95% of people know better...this will eventually stop the vicious cycle...

mcspiff, your points are whishy washy. You dont even seem like you have a solid argument here. You just seem to argue for the sake of arguing at this point.

truekaiser · Post by **truekaiser** » Wed Dec 22, 2004 10:40 pm

mcspiff wrote:And dropping Cflags filtering wont get said hissy fight?

good point.

mcspiff · Post by **mcspiff** » Wed Dec 22, 2004 10:46 pm

Im going to outline this very clearly lockheed.

Not checking input from the user is bad. This is espically bad if it disruptes the fundemental functions of the program. This leads to security problems, segfaults and other nasties. Most programmers will tell you, either ignore the input if its non-vital, in the case with Cflags or die with a helpful error message.

If the user does not want this default, correct behivor, provide an option to over ride this error checking. If you do not, people with either realease "faster" ebuilds or copies or portage with the error checking disabled. This does help anyone.

If a user is not willing to listen to these forums, nothing can stop him from using his two pages of Cflags. At best, we can help those who were merely told to use these Cflags.

Lokheed · Post by **Lokheed** » Wed Dec 22, 2004 10:56 pm

mcspiff wrote:Im going to outline this very clearly lockheed.

Not checking input from the user is bad. This is espically bad if it disruptes the fundemental functions of the program. This leads to security problems, segfaults and other nasties. Most programmers will tell you, either ignore the input if its non-vital, in the case with Cflags or die with a helpful error message.

If the user does not want this default, correct behivor, provide an option to over ride this error checking. If you do not, people with either realease "faster" ebuilds or copies or portage with the error checking disabled. This does help anyone.

If a user is not willing to listen to these forums, nothing can stop him from using his two pages of Cflags. At best, we can help those who were merely told to use these Cflags.

You should have outlined your argument. I dont need a lecture on filtering CFLAGS and the reason its necessary to keep programs running smoothly. But we arent talking about filtering out O3 for O2, etc. We are talking about filtering CFLAGS that should not be used under any circumstances. We are talking about trimming back CFLAGS to very safe and respectable levels...right?

I dont understand the second part of your second paragraph. Besides whats really the point in having 3 pages of CFLAGS when 80% of them are filtered anyway. It just creates more work for everybody. Work that could be spent on improving Gentoo, and not coddling ricers...

There isnt much point to what you suggest other then moving Gentoo along at the slowest pace. Gearing to the lowest common denominator doesnt work for me.

"Make a tool idiot proof and only an idiot will use it" Murphy's Law

mcspiff · Post by **mcspiff** » Thu Dec 23, 2004 3:32 am

I had a long winded reply, but my browser crashed
For your first paragraph, yes have portage trim back to a list of safe Cflags

For your second, how does this make more work for anybody? its obvious there is a very small list of safe flags. Have portage filter everything else out. No mess no fuss. Saves developers time, as Cflags will no longer be the prime cause of bug reports. If someone wants to waste their time generating a three page Cflags list, with only 4 or 5 sane ones actually being used by portage and then rest silently being ignored, no one is harmed, and the ricer class will soon die out as people realize that all their magical flags are simply ignored.

wdreinhart · Post by **wdreinhart** » Thu Dec 23, 2004 7:08 am

mcspiff wrote:If someone wants to waste their time generating a three page Cflags list, with only 4 or 5 sane ones actually being used by portage and then rest silently being ignored, no one is harmed, and the ricer class will soon die out as people realize that all their magical flags are simply ignored.

That's not The Gentoo Way (tm).

Gentoo doesn't force a sane partition layout on you, or force you to use a developer approved filesystem or prevent you from using a love-sources kernel. Gentoo assumes that if you know what you're doing, and hands you enough rope to hang yourself with. Why should it force sane, developer-approved cflags? Users should learn for themselves why fewer cflags are usually better, and re-installing from stage1 after their whole system got hosed by building everything with "-O4 -funroll-loops -ffast-math -fomit-opcodes -mbreakstuff -fbreak-more -freplace-branch-predictions-with-random-gibberish" can be very instructive.

Lokheed · Post by **Lokheed** » Thu Dec 23, 2004 7:22 am

Exactly what wdreinhart said. mcspiff, what's the point of giving this false sense of control to a user when 95% of USE Flags do nothing because they are filtered out, why then should we keep them in circulation? Whats the difference from elliminating the CFLAGS or filtering them out so they cannot be used?

The more you write the more you lose me. But that is not a solution to simply hide some setting somewhere to filter all of them out...besides its not as simple as that as its been stated. Some can use O3 and others cant, some can use -fomit-frame-pointer and some cant...its not as simple to filter out CFLAGS as you think as some do benefit some packages...but whatever, I said me piece, dont need to say anymore...

Conclusion=Ricers just plain suck.

lightvhawk0 · Post by **lightvhawk0** » Thu Dec 23, 2004 7:46 am

i've always just manually edited all the ebuilds making sure my cflags will work and I always read the bug reports making sure that I don't repeat a mistake. IE -fstack-protector-all kills python so I don't use it with python.

So I'd like to try and think of ways to make it so you can use your cflags and have the documented "bad" flags for that ebuild together, not filtered just in a place where you can check it and go "oops I'm a dumbass it's documented here that this flag breaks this package, duh"

Also this would help let us know when a cflag becomes usable again.

I'm gonna stick to this idea because I think it would be helpful to help the ricers , sane people and developers.

or even the idea of a package.cflags where you can use specific cflags for an application, like encoding makes heavy use of the fpu, you you could store some useful fpu sensitive cflags there.

and if this is just a cry in the dark at least sombody saw it

macawgumbo · Post by **macawgumbo** » Thu Dec 23, 2004 8:54 pm

I have a computer acting as a server with command line only. It is running with an AMD K6-2 500MHz proc and needs to be as fast as possible with the cflags and etc.

Code: Select all

CFLAGS="-mtune=k6-2 -pipe -fomitframepointer -02"

Any suggestions?

PS: Running SELinux

spb · Post by **spb** » Thu Dec 23, 2004 10:40 pm

macawgumbo wrote:Any suggestions?

Yes. Leave your CFLAGS as they are.

PS: Running SELinux

Good man.

virtual · Post by **virtual** » Sun Dec 26, 2004 12:07 pm

Hi,

These are my CFLAG settings and I have no problems, but I use KDE only except for gdm.

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags"
CFLAGS="-O2 -march=pentium4 -pipe -ffast-math -fforce-addr -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"

My use flags:
USE="-gtk -gnome -f77 -fortran -oss qt kde dvd alsa cdr cups foomaticdb ppds usb nptl mmx sse sse2 pic doc"

I use gcc 3.4.3 and prelink. I think and hope these are optimal because I do not know what else can be done to increase performance. All hints are welcome. Why do many people write down every flag they use when most of the time they are implied by the -O2 or -O3 except for the -fomit-frame-pointer on the x86 arch.

rhill · Post by **rhill** » Tue Dec 28, 2004 2:08 pm

truekaiser wrote:the only strange stuff i have in my make.conf is '-mmmx -msse' mainly cause i read that sometimes -mcpu=pentium4 doesn't pass those on. and i don't have -msse2 on cause it breaks some packages.

that's a myth. it's been proven many times on the gcc mailing lists. if i weren't so tired, i'd find you a reference(s).

tnt · Post by **tnt** » Thu Dec 30, 2004 4:27 pm

I've compiled my system with a lot of CFLAGS and had a lot of segfaults and hard lock-ups. Now that I've read this thread I want to switch to simple:

Code: Select all

CFLAGS="-O2 -march=athlon64 -pipe"

How to do that?
Is it enough to set new CFLAGS in /etc/make.conf and run

Code: Select all

emerge -e world

or run

Code: Select all

emerge -eD world

or I sould do bootstraping and all other things I've done in the instalation process?

gentoo_lan · Post by **gentoo_lan** » Thu Dec 30, 2004 4:52 pm

I would do an:

Code: Select all

emerge -e system && emerge -e system && emerge -e world && emerge -e world

tnt · Post by **tnt** » Thu Dec 30, 2004 5:13 pm

OK, but can you just tell me why to run

Code: Select all

emerge -e system

before

Code: Select all

emerge -e world

if "system" is included in "world"

And even more confusing is why to run both of them twice?

TrueDFX · Post by **TrueDFX** » Thu Dec 30, 2004 5:56 pm

tnt wrote:OK, but can you just tell me why to run
Code: Select all
emerge -e system
before
Code: Select all
emerge -e world
if "system" is included in "world"

And even more confusing is why to run both of them twice?

robmoss wrote:The first command ensures my toolchain is in order; the second ensures it's been compiled with a clean and current toolchain; the third recompiles all my packages with a clean and current toolchain; the fourth ensures that all my packages are compiled against packages compiled with a clean and current toolchain.

HTH

tnt · Post by **tnt** » Thu Dec 30, 2004 8:21 pm

Well, I doubt that...
Let's see: package-X depends on package-Y and will compile against it.
With command "emerge -e world" all packages in the system would be compiled in order that satisfies all dependencies.
So, package-Y would compile BEFORE package-X and package-X would be compiled against clean, new package-Y.
Same situation with "emerge -e system". There would be no packages wich compiles against some other package that is not already clean (recompiled with new flags).
All about dependencies and order of compilation...

racoontje · Post by **racoontje** » Thu Dec 30, 2004 8:26 pm

Dude.

O. T. T.

Don't give the "Gentoo is Rice" people a reason

irf2003 · Post by **irf2003** » Thu Dec 30, 2004 8:52 pm

what robmoss recommended is extreme, this dev plays with fire, so he has to be cautious.
in most cases:

Code: Select all

emerge -e system
etc-update && env-update && source /etc/profile
emerge -e world
etc-update && env-update && source /etc/profile

the above should do.
hth
happy new year
PS this step is very important

Code: Select all

etc-update && env-update && source /etc/profile

TrueDFX · Post by **TrueDFX** » Thu Dec 30, 2004 9:02 pm

tnt wrote:Well, I doubt that...
Let's see: package-X depends on package-Y and will compile against it.
With command "emerge -e world" all packages in the system would be compiled in order that satisfies all dependencies.
So, package-Y would compile BEFORE package-X and package-X would be compiled against clean, new package-Y.
Same situation with "emerge -e system". There would be no packages wich compiles against some other package that is not already clean (recompiled with new flags).
All about dependencies and order of compilation...

In most situations, you're probably right. However, not so with indirect dependencies on the package itself. For example, libsdl can depend on directfb, and directfb can depend on libsdl. Which should be compiled first?

Lokheed · Post by **Lokheed** » Fri Dec 31, 2004 9:23 pm

racoontje wrote:Dude.

O. T. T.

Don't give the "Gentoo is Rice" people a reason

LOL, thats funny. I dont think you know why they call them "ricers"