[Raion]

Ok, so the GCC guides and build systems out there that allow GCC building, all in all are filled with well-intentioned but often outright contrary to proper GCC guidelines for building a working compiler without a lot of pain. Part of this is why I'm doing something about this. 

Let's start:

1. Many patches directly edit fixincl.x, for the fixincludes part of GCC. This is not supposed to be done. I know /why/ many people do this, mind you, but it makes it hard to port patches between GCC versions. This requires autogen and guile to be installed, and thus is a bit more of a pain in the ass, but I will not, for any future source tree patches I publish. Otoh, for prepatched code that's ready to go, and has sufficient instructions, this is probably not an issue. Thankfully, many of the patch authors have also applied them to the include definitions that are called to build fixincl.x, so that's helpful at the very least if you need to regenerate that. 

2. I've been building the libs and such out of tree, but everything I've read from GCC literature, as well as the advice of a good friend whose developed for GCC in the past, has indicated to me this is not the right way to do it. You should use contrib/download_prerequisites whenever possible, or if you have your own versions of GMP, MPC, MPFR etc to build against, put those in tree. This is also easier if you intend, as I do, to have multiple GCC versions installed. I would rather, because all of these are basically reinstatements of GCC, have as much coverage through known-good versions and multiple points of potential failure; if a particular version of GCC does better with a certain program, we can help keep track of this between ourselves. I do usually put GMP out of tree, but that's because I have a lot of small patches for it and some custom configure scripts I haven't figured out how to pass to GCC downstream. I WILL be updating the script with the particulars of what versions I used, and the commands I used for them.

3. IRIX tar has path length limitations that cause some path names on GCC to get corrupted, usually for libstdc++ and parts of the testsuite. star, gnu tar, and bsdtar from libarchive all work. I have a schily tar tardist available as well that makes this easy. 

4. After I get the GCC versions all built, I plan to go back and see how hard is it for us to patch them using IRIX ld and IRIX as. I don't know if this will make any differences code or performance-wise, but like many of us here, I'm leery of binutils. Danielhams' patches are pretty good and I've had only a few weirdness issues from them that I was able to solve with some ease; sometimes though I wonder if IRIX's ld or as can do better, as a few users here prefer the use of IRIX's as for perceived ASM benefits. I found some longstanding bugs that broke bootstrapping, and some unfixed GMP bugs that an old pkgsrc post came up with. 

5. LTO appears to be broken, both for the didbs builds, and for Erno's builds, as well as Nekoware's GCC. This is also true of mine

6. I am releasing a new Nekoware I GCC compiler. This will mostly be for the benefit of those who have any interest in Nekoware 1 -- Nekoware II is gonna happen... eventually.