dbn.lists at gmail.com
Sat Feb 10 11:34:28 PST 2007
I think you know this, but just to make sure, any breakage from
optimization is on you. The LFS books are written the way they are for
exactly the reasons you're asking. With that out of the way...
On 2/10/07, Athena P <lists at vega.uk.net> wrote:
> Firstly I have successfully built glibc-2.3.6 using the following
> optimization, this is including running "make check" to ensure no
> fundamental build errors. "Make Check" reports no errors!
> 1] "-O3 -march=prescott -march=prescott -mtune=prescott -mmmx -msse
> - msse2 -msse3 -m3dnow -pipe -mfpmath=sse"
If this passes all of make check, then I'd go with it. If adding more
math optimizations breaks make check, then remove them. For reference,
the Fedora guys (who develop glibc) build with these flags on x86:
"-march=i686 -mtune=generic -DNDEBUG=1 -fasynchronous-unwind-tables -g -O3"
And for the rest of the system, I think it's
"-g -O2 -march=i686 -mtune=generic -pipe"
+/- any package specific settings.
> My GCC is gcc-4.0.3 and is build with default optimization; I assume
> it's not a good idea to heavily optimize GCC, would this be right?
Optimizing gcc isn't gonna buy you much. You can compile faster, but
the target code would hopefully be compiled the same no matter how you
built the compiler.
Optimizing glibc is where you'd actually see a difference in your
system. Everything on your system links to libc and uses ld.so. So,
making them work faster in turns speeds up your whole system. The flip
side is that if they're broken, then everything's broken. That's why
we tell people to use the default CFLAGS and always run the testsuite.
> Is my first optimization sting  safe to use for the libc and is the
> second string  safe to use for higher level parts of my system?
Maybe, maybe not. I don't think anyone here is familiar enough with
gcc internals to know how stable those switches are. Also, it depends
on the code you're compiling. For one package, optimizing the math
routines might change nothing. For another, it might break.
I don't think anyone can really say whether those settings are safe or
not. I think probably you just have to do it and find out if your
system is stable. Or just use a safer set of defaults.
All in all, though, I don't think heavy use of compiler optimization
flags buys you that much in the end. Other things such as dynamically
loading lots of shared libraries are probably going to cause a much
more noticeable slowdown than a particular binary not being heavily
More information about the lfs-support