I’ve spent the day trying to compile old versions of GCC.
GCC itself seems okay – but binutils is a freaking catastrophe.
Binutils is basically fucked. AFAICT, all versions compile with warnings, and all versions have warnings-as-errors turned on.
Remember that I’m building binutils through GCC – just putting the binutils source dir into the GCC source dir and letting GCC do the work.
I think now that –disable-werror passed to the GCC ./configure propagates to the binutils ./configure; this has got me to the point now where the binutils (2.17) build seems to be breaking because… it’s trying to call something called “cc1obj” and it can’t – rightly so, because it’s not there – but I *think* cc1obj is actually the *Objective C compiler*…
I’ve also found out GCC depends on a couple of external math libraries, which I also need to download and have GCC build, so I need to add them to the version matrix in the docs.
2.27 will build, but it emits its “ar”, etc, into the a directory which is different to the directory GCC looks for them in.
I guess maybe later GCCs look in the right place, so I should stick to the chronologically matching binutils version (2.17). So I go back to 2.17. I install the Objective-C compiler and the “can’t exec cc1obj” bug is fixed. So binutils is in fact dependent on Objective fucking C. It would be nice if I could find some – ANY – documentation on this. We are however talking Linux, which means broken-out-of-the-box-with-no-docs. They say there’s no guarantees with Linux. Believe me, this isn’t true. There really *is* a guarantee.
So, Objective C installed and now we’re on to the next problem – which turns out to be that modern gnumake has a built-in rule for the suffix “.m”, and that built-in rule is wrong for the gprof makefile.
I mean, shit. If you’re going to fuck it up, fuck it up REAL GOOD.
More later. So I checked the release dates on gnumake. Sure enough, looks like bunutils 2.17 would have been built with 3.80, and 3.80 doesn’t have an implicit rule for “.m”.
So I download 3.80, make it, put it in /usr/local/bin.
Now here’s the thing; which make gives me /usr/local/bin/make.
But “make -v” gives me version 4.0.0 – the make in /usr/bin.
If I rename /usr/bin/make to /usr/bin/make.old, I get a “can’t find file error” when I do “make -v”.
In other words, there is a totally unexpected hidden extra layer masking which make you use. WHY THE FUCK DOES THIS EVEN EXIST?
Why do I even HAVE /local IF THE OS IS GOING TO HARD CODE USE OF /USR/BIN?
It’s bullshit enough trying to compile binutils without the operating fucking system pulling shit like this AS WELL.
I think I’ve hit the end of the road with 2.17. I *can’t* make it compile. I think it probably it acting properly on the .m files, it’s just that one of those files is actually really broken – or anyway, broken maybe so if you somewhat could telepathically know the right config you could fix it, but that means all seven billion humans on planet Earth can’t fix it.
So I decided to have a look at version 2.17a – maybe it’s a bug fix?
Guess fucking what. When you untar it, it untars to “binutils-2.17”, not “binutils-2.17a”, thus over-writing your existing directory. FUCKING MORONS.
If this is what I can expect from binutils, then I am a fucking idiot for trying to make it compile.
More more later.
The earlier version I can make build is 2.20.
However, this has the same problem (at least with GCC 4.1.2, assuming GCC version is relevant) of emitting its binaries into a directory which is different to the directory GCC is looking in.
I’ll try a later GCC to see if it makes a difference.
So, GCC compiles and binutil compiles. I presume libgmp is compiling too, since it’s in there.
The problem now though is that the GCC docs are fucked. They won’t make.
Turns out the doc files with 4.4.3 (and prolly a bunch of older versions) won’t work with more modern versions of texinfo. Looks like there is a workaround.
Basic lesson here. If your code has a dependency on ANYTHING – A N Y T H I N G – then in a couple of years, your code will not build because of that dependency.
Well fuck me – the workaround does fuck all. I’m so surprised. The idea of the workaround is right though – explain to configure there’s no texinfo and not to make docs.
So I’ve uninstalled texinfo. That seems to have enabled me to move on to the next set of errors, which are that libmpfr is missing – which is a valid error, as I’ve not put that library into the GCC source tree.
I need to figure out which version to use though, and it’s bed time now – it was bed time 1.5 hours ago.