With the toolchain rebuild for binutils-2.20, I decided it would be good idea to use package splitting to create the gcc and gcc-libs packages as that saved me a lot of build time. While I was at it, I split gcc-fortran, gcc-objc and added a gcc-ada package.
That was when I ran into fun… Once I had built gcc with package splitting, I decided to attempt to rebuild it again with the new packages just to make sure everything was OK. Turns out, that was not the case. The C pre-processor was failing basic sanity checks and that falls into the category of “not a good thing”.
So I compared the list of files in the split packages to the originals as I made quite a few changes and could have plausibly “lost” some files. Everything seemed as expected. The only real difference was the “fixed” include headers were gone. This was also expected as the previous PKGBUILD had this line:
# Remove fixed includes, either no need for them, or they're not complete
rm -rf ${pkgdir}/usr/lib/${CHOST}/${pkgver}/include-fixed/*
That comment is quite correct as the gcc packages are built in a minimal chroot and all headers in the packages within the chroot are in no need of fixing. However, earlier in the package splitting process I noted that the fixed includes directory was actually in /usr/lib/gcc/$CHOST/... and not /usr/lib/$CHOST/..., so I fixed the PKGBUILD.
And here was the problem… As of GCC-4.3, the compiler installs a limits.h file into the private include-fixed directory and that directory is an absolute requirement. So, the unnoticed bug in the PKGBUILD actually was saving us from a far more severe bug and had been for some time.
The only conclusion I can draw from all of this is we should never strive for bug free code as some bugs are good!
Pingback: ghostship 0.4: some major rewrites « Thoughty's Blog