So I recompiled gcc. The intent was to add Fortran (I used it ages ago and darn it I may just want to try it again) and Go (I have some curiosity about this relatively new language).

Naturally, I followed the directions of the BLFS8 (stable) book. I figured that since I was compiling the same version of GCC that I had already in-place, things should go OK? Right? I hope?

Ran it. No obvious errors during sed, configure & make.

Then I ran "make -k check". The process ran for some time (expected) but I did not expect the check itself to fail and that is what looks like has happened (quote instead of code, so it wraps):
The above is not the complete output. It is all that screen had retained when I decided to copy-and-paste it. Near as I can tell, the last few error lines are not in any log. Those last few lines are what look bad.

Speaking of logs, following the guidance of the book, I was able to render this summary:
The book mentioned that if one has valgrind installed (I do) there will be more errors than mentioned in the book.

I checked other people's logs, who used a similar architecture, such as http://gcc.gnu.org/ml/gcc-testresult.../msg03046.html
but the numbers differeed enough from mine that I could not make a judgment.

I cannot determine from the data available if my GCC build is good or not.

At this moment I have not performed the "make install" and I would please like the opinions of those here. Thank you very much.

make -k check will allow the tests to continue, if there are errors. As for your errors...

I've seen all of these myself on more than one build. None of them has ever caused any sort of issue later and those system were built all the way to functional desktops.

1 members found this post helpful.

Does that mean that my "make -k check" run to completion (ie, ran every test)?

This is encouraging, thank you. My BLFS system right now is my main desktop system, so I am a bit more cautious.

It looks like the best thing for me to do is a complete backup, the make install, reboot, then test the compiler by recompiling seamonkey.

Yes, the "-k" stops it from bombing out when a test fails.

Recompiling SeaMonkey may be a bit extreme. There are a couple things the book forgets to mention about tests. First, they're the lowest priority to be updated by developers. In the OS/FS community, new bells and whistles come first, bug fixes or code spec updates are a grudging second and, at the bottom, lies updating tests that newer code has broken. Second, the tests can easily be broken by a build environment that's not very close to the developer's. Virtual environments, different processors... hell different memory timing (overclocked) can probably break some.

The important things to look for are a lot of fails and/or a lot of fails on a specific page of code and anything with functions derived from that page of code. If you get a ton of floating point division errors followed by a lot of failing advanced math tests (sin,cos,tan,Fourier) then that's a good indication something is actually broken. Likewise, if you get an error regarding the handling of bitstream data and then lots of file/pipe/network function tests fail, chances are good something is actually wrong.

The last time I had an actual problem... I made a mistake in
"Adjusting the Toolchain (Chapter 6)". Running "make check" on GCC produced more than 20,000 errors in just a few seconds. So, if you've made a major mistake, it will become apparent very quickly in most cases.

1 members found this post helpful.

Ahhhh, interesting. Thank you.

Still gonna recompile seamonkey afterwards: if that huge tower of cards actually compiles, then I *know* the compiler is good. Overkill works.

Recompiled SeaMonkey. No problems. GCC is good. Thanks for the replies.