Hi. I have been thinking that, at least with -unstable, we should do as much as possible to improve our ability to debug and stabilize the base packages.
There are two ways I can think of dealing with GCC optimizations. Either use every GCC optimization on every package and then debug them, or use no optimizations. Using every optimization will surface the most possible bugs, and create the most possible work to do. Using no optimizations does not fix anything, but makes it less likely that invalid/incorrect code will cause a problem. We are already using -pie, fortify_source, and -fstack options which still have unknown results with many packages. It's more realistic, for now, that we use the fewest optimizations possible to prevent unknown bugs from surfacing, even though this is like sticking your head in the sand. For the most part this is what LFS already does, but a few packages are exceptions. GCC uses -fomit-frame-pointer during bootstraps, and at least one package uses -funroll-loops. GCC also uses -mtune=pentiumpro by default on i686's. For the sake of stability and debugability I think we should disable these, and stick with only using -O2, -g, and -Warning flags. --with-cpu=i386 can make GCC drop the -mtune down to i386. I would also like to install Valgrind in /tools so GCC can use it with --enable-checking. I haven't checked, but I would imagine the internal consistency checks all pass in the recent gcc releases, however the -pie, fortify_source, and -fstack options may or may not affect the results. Enabling all the internal consistency checks would probably send a GCC bootstrap into the 30-50 SBU range, but would also serve to verify we are using a solid/stable compiler. This would be best done in the final GCC installation, in chapter 6. Valgrind, and Lint/Splint, can also be used later to test the rest of our packages as a part of a base system audit. Some packages are unauditable by hlfs, like Glibc, but it would be reasonable to set of goal of auditing the suid programs, and document how it was done so users have a reference that can be used for blfs packages, like daemons. And then there's libmudlap. I think it'd be a good idea to link suid programs to libmudflap on production systems, but linking the entire system to libmudflap would probably make the system unusably slow. However there may be some of us willing to devote test systems which run hlfs with all possible debugging, either running some network services, or perhaps weekly rebuilds with the help of jhalfs in some sort of rc5-like challenge which looks for bugs in new packages. It should be easy to add -lmudflap to gcc's specs so the entire system is linked to it, for these test systems. GCC Valgrind tests, and alike, can be relaxed or removed from -stable hlfs releases for the sake of keeping the build time sane, but in -unstable it would be worth it. Comments? robert
pgp3pmSZR6G2K.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
