> This was for two different occasions, just that my linebreak > dissapeared: > > package specific optimizations aren't handled unless you do it on > commandline. > > some packages are known and documented to break with certain flags, and > if those flags are in the common area (-O3 comes to mind) they are > filtered out and removed. Some packages don't even like -march= but > will sod off and generate segfaults the next package thats built (cause > its used in the buildprocess) . We fix that by overriding CFLAGS for > those specific cases. (sandbox is a good example. it breaks using O>1)
Ahhh...so you DO care ;- ) I suppose then there may be interest in any Flag/Package combinations I find to be not workable. Perhaps on gentoo-dev? > > This Larry the Cow likes insane CFLAGS optimizations! > > Yes, go play with them, but what we are protecting here isn't users who > compete by the size of their CFLAGS, but ourselves from packages that > don't build with either the default (-O2 -march=) or"recommended" (not > by me) -O3 . If I didn't want performance I would've walked right past gentoo and complained that the install process wasn't "pretty enough" or "idiot proof". I do like (really like) what we have here with gentoo...I'm just looking for a _LITTLE_ more control over it. This brings up 1 more question (you're probably not going to like)...if there's a custom patch (possibly private - say for preferred keybindings or something) I'd like to apply to a package before compiling...is this possible as well? > > This is sort of what the LFS (linuxfromscratch.org) boys told > > me...well no, their motto is FBBG (Follow Book, Book Good). > > > > <cut> (since you didn't tell me what measure of "stable" was, nor what > os said system was for I'm blatantly ignoring this) What other OS than Linux would linuxfromscratch be? I DO admit that I did minimum testing on this...so I probably shouldn't have said "stable", more like "it booted". > > I really can't think of a package that would benfit overall system > > performance from optimization more than glibc - it's used by > > EVERYTHING! > > Ahh, so thats why theres processor specific assembler all over glibc. > Glad to know. It's not really "all over" glibc. Most (if not all) is contained in glibc-version/sysdeps (also glibc-version/linuxthreads/sysdeps) and is included as needed based on your HOST setting. You may have looked further into this than I but I'm pretty sure I didn't imagine it compiling and working for me (though it hasn't been tested thoroughly). -- [EMAIL PROTECTED] mailing list
