The compiler toolchain – updating an old Linux system pt.3

In the previous two posts I showed how to install ConnOS (website here, will vanish at the end of 2013!) and demonstrated how to update a few important system components. Today we’re in for more updating fun: We’ll be rebuilding the whole compiler toolchain and replace the pretty ancient versions available on ConnOS with far more current software.

Updating the toolchain

Now that our system is much easier to work with we’re ready to go on with the more important stuff, right? Right. The first package we’re going to update is the api-headers of the kernel. Since we’re going to stick with Linux-libre (a variant of Linux that has each and every binary blob removed from the kernel), we can get a PKGBUILD over at Parabola GNU/Linux.

Downloading the PKGBUILD file from Parabola

There’s not much to say about it except for the fact that it needs the kernel source which is really big (about 70 MB!). In building and installing it there’s nothing special.

Normally our next candidate would be tzdata, which contains time zone information. However it won’t build yet as the zic tool is not available in ConnOS’s native eglibc. For that reason we will have to build a more current libc first.

Installing new api headers

This means we’re in for a special package: The system’s standard C library. Most Linux distributions use glibc which is rather fat and lavish but also has the best level of compatibility with most applications (due to it being the de-facto standard). ConnOS uses a glibc variant called eglibc which has some patches applied to make it work better on embedded systems (and thus on all kinds of machines with low resources). Unfortunately neither Arch nor Parabola use it and even on the AUR there’s only an ancient version of it (just barely newer than the one ConnOS ships).

The eglibc project also doesn’t seem to provide source tarballs. Instead the source is always cloned from their repository. However we’re not going to mess with a VCS (Version Control System) now. Fortunately there are projects using eglibc which provide source packages for it. Debian does and Cross-Linux-from-scratch does, too, just to name two. We opt for the later since it offers a more current version.

So our best bet with eglibc is to take the very old PKGBUILD from ConnochaetOS and update it to build a newer version. This is actually a bit tricky. If you want to save yourself some time trying everything out you can just use the PKGBUILD I prepared.

Installing a new version of eglibc

For some reason makepkg has difficulties with the packaging of this one. It creates the pkg directory with too restrictive permissions and fails to go one with package building. The easy solution here would be to simply use sudo since root is allowed to write anywhere. However package building as root is strongly discouraged – for a good reason. If you’re not absolutely sure your PKGBUILD is completely correct, some files could end up being installed to wrong paths on your real system, creating a glorious mess! So we’re going to take the right path and avoid dangerous root packaging. Which means we have to fix that directory issue. And right: It’s actually as simple as changing the directory permissions in the PKGBUILD.

Once it finished building (which can take a while) we’re going to install it. Since the contents of the package has changed compared to the older version we have to install the new one with the –force parameter, allowing to overwrite files owned by other packages currently installed (-f as we used before doesn’t work with the updated pacman anymore…).

Now that we have replaced eglibc version 2.11 (sic!) with 2.18, we’re good to build and install tzdata. It’s an unproblematic quickie.

Installing current tzdata

On to the next step: Updating the binutils package. Binutils consists of several tools needed whenever binaries are created: like two linkers (ld and gold), an assembler (gas), the stripping tool and some more. It’s one of the bigger packages and thus takes a while to complete. Other than that there’s nothing special here.

Upgrading binutils

Next in line: The GMP library (providing some advanced math functions). Again building and installing it is nothing special. However the library received what is called a soname bump. The non-technical explanation of that is that the number after the “.so” (for shared object) extension increased. But since many applications (including e.g. GCC and pacman!) were built against the old one, they expect that it is still available and will be missing it after installing the new one.

In theory we should now rebuild all (!) packages which depend on GMP so we have a clean system again, working entirely with the new one. Of course we’re not going to do this now and even if we did plan to do so, we first need to make GCC work again. We do so by softlinking the new library to the file name of the old one with the command: sudo ln -s /usr/lib/libgmp.so.10.1.2 /usr/lib/libgmp.so.3

Updating the GMP library

The old GCC present on our system uses a package called cloog-ppl. It does no longer exist as cloog and ppl are separate packages now. With newer GCC versions ppl is now an optional dependency. And since it also is a monster of a package (compiling it on an 1.6 GHz Pentium4m machine took over 40h!) we’re going to drop it. You most likely don’t feel like building it on a pc you’re using ConnOS on, anyway, do you?

Our updated GMP enables us to build a new package – isl – which itself is a dependency of cloog. So we’re building and installing both of them.

Adding the new package isl to our system

Isl shouldn’t be a problem at all and cloog only needs to be installed with the –force parameter, as it needs to overwrite some files of the old cloog-ppl package. Of course it would be better if we could just remove the conflicting package. Unfortunately it’s not that easy in our case. Said old package is needed for the currently installed version of GCC to work so we currently have no chance to uninstall it without breaking the compiler and rendering our system useless for the further updating process.

Installing cloog

Thanks to the updated GMP we can also update another library which depends on it: mpfr. The one on our system is very old and like GMP it has received a soname bump in between. Since it’s also a dependency of GCC, we need to symlink the new library to the names in use with the old version (see the picture for details) or our compiler will be broken.

Updating the mpfr library

The last library in line is libmpc. We’re going to update it right now as it’s one more dependency of GCC. It’s soname hasn’t changed so we’re good with the update and don’t need any symlinks this time.

Updating libmpc

Finally we’re in for the true bigwing of our update: GCC! We’ve built all the dependencies for it in their newest versions available. However we’re not going to build GCC 4.8x and opt for 4.7x instead. Why? Simple. I had first built 4.8 before and all seemed to be working well. Then however I came across a rather special package required to go on. It builds its own temporary toolchain since it’s only known to compile well with certain versions of the compiler and libraries. Now for some reason (one of the more or less frequent regressions) GCC 4.8x is severely broken: Building older versions of GCC with it doesn’t seem to be working easily! And since I passionately hate software broken in such a way, I’ll ignore that there is such a thing as GCC 4.8x. Period.

For that reason we’re going to build GCC 4.7.3 (a version Arch never used since they went from 4.7.2 directly to 4.8.0). If you want to use the PKGBUILD I prepared, it builds GCC fit for the languages C, C++ and fortran. We won’t need the later right now and thus I also don’t install it yet. But there are some important packages that use fortran. So it’s good to support it, too. GCC takes very, very long to build, btw. Depending on the speed of your machine, it may even be a good idea to start building it over night.

Updating GCC

Now we have to build libtool and libltdl. Don’t look for the PKGBUILD file of the later; it’s part of the libtool source package. Also don’t ask me for what reason they are being packaged separately now…

Even if there was no new version of it, we would now rebuild libtool. Why? Because we’ve just built GCC! Libtool is tied to GCC very closely and needs to be rebuilt as well if GCC changes. Another thing about libtool which is important to know: Due to its close ties to GCC you should avoid just updating one of the two. If a new libtool is released it’s meant for the recent version of GCC and not for older versions. Also newer versions of GCC may be meant to work with current libtool and you can run into trouble if you stick with older versions. Just keep that in mind to avoid unneccessary issues.

Updating libtool

Now as a last step we need to rebuild and reinstall two packages we’ve built before: binutils and eglibc. The reason is that binutils should be rebuilt with the current version of GCC (the previous binutils package was built before we updated the compiler) and the C-library was built with both the old GCC and the old binutils. Once we’re done with these two packages we again have what is called a sane toolchain. With the big difference of course that it’s more than two full years newer than the one our system had before!

That means we’re done with the task of today’s post. Having taken a crucial step this time, we’ve already gone a fair bit on the path of updating ConnOS. But still this is just a start.

What’s next?

I’m considering to write one more updating post. But honestly I’m not quite sure if I should. Free time is a scarce resource. And thinking about how short the rest of 2013 is and how many topics there are which I’d like to write about in the remaining one and a half months… Well. I simply don’t know right now. Feel free to comment on this topic and tell me what you think. Would one more update post be a good thing or should this be the final one?