The (building) GCC blues
I have spent most of today building GCC 4.7.2 in our Debian Linux based development environment at work. Now that I've got a viable 4.7.2 compiler, I just started building the 4.6.3 compiler alongside it. What a way to waste a day.
And yet, so familiar. When I leapt into the world of commercial software for the UNIX platform, way back in 1991, we needed a way to level the playing field on the numerous versions of UNIX we were developing for. My product, Security Toolkit/UNIX, was a security analysis package. It was the digital equivalent of the type of security guard known as a 'doorknob rattler', the guy who walks around the warehouse at night making sure the windows are closed and the doors locked. We had a relatively long checklist of settings we would poke into, and rate your systems security posture.
By the time it was a year old, this product ran on Ultrix on MIPS and VAX; SunOS on M68K and SPARC, HP/UX on M68K and HPPA, and AIX on the Power platform. Not long after that the sales people found Data General Aviion, Motorola, and Intel all sold UNIXy systems, and the race was on. By the time I left Security Toolkit/UNIX, as it was becoming Enterprise Security Manager, it was running on 18 different UNIX platforms.
One of the ways we kept the craziness down in this plethora of CPU architectures, UNIX variants, and operating systems quirks was to rely on GCC for compiling and GNU make for building the software. We had a single source code tree that built STK on all of these architectures, and it would have been much harder if we had to code around individual compiler quirks on every platform.
Most of the machines we only had one of. We occasionally got pushed to dual-boot a machine for a more obscure UNIX variant, but we always managed to push back enough to get at least one machine for each system we were required to build on. In many cases (the m68k build for SunOS leaps immediately to mind) it actually took longer to build our standard compliment of GNU tools than it did to port the software and have it working (just over 3 days, vs just under 2; the SunOS/m68k port was done the week before the Christmas party.)
Because disk space was fairly expensive in those days, we generally built the GNU tool chain once for each platform, and exported it via NFS. This became a central part of our strategy; no matter which machine you were logged into, your home directory was mounted (often via automount) on /home/username, and the GNU tools were available in the /tools directory tree. If you had /tools/bin in your path, you were ready to develop, debug, etc.
Upgrades to the compiler were a big event. Our slowest machine, a lowly VAXstation 2000, had almost exactly 1/60th the compile speed of the fastest machine, an early Alpha workstation also from DEC. The Alpha would compile STK in 20 minutes, the VAXstation took 20 hours. The 'product build' process was a script that would rsh to each machine, from fastest to slowest, and start the build process. Upgrading GCC would take half of our 4 developers out of product development for a week, so we only did it when we had a compelling reason. Usually this was fixing bugs in the HPPA or Power code generators, but hey, those architectures made us money so it was worth the pain.
So why am I building GCC for Debian today? We are experimenting with some of the C++11 features, and the default compiler for Debian Squeeze, our base, is 4.4.5. The 4.4 branch doesn't have lambdas, which we are pretty sure we want, so we're going to jump to (probably) 4.6 to get lambda support. The 4.7 build is mostly so we can sanity check it and see how it's coming along, plus it turns out that 4.7 is easier to build with 'current' versions of some of the build prerequisities like gmp, mpc, and mpfr.
This will bring up the inevitable question from the Debian crowd: "Why don't you just install a deb?"
Simple: the Debian "experimental" GCC packages are STOOOOOOOOPID.
Why would anyone want to replace their system compiler with an experimental one? GCC makes it very straightforward to install a second (third, fourth, etc.) compiler version alongside the system one, so why does the Debian experimental package replace the system compiler? The FreeBSD Ports system, always my paragon of how to do things correctly, allows you to install any number of GCC versions side by side; you just run gcc-4.6, gcc-4.7, etc to get the compiler you want.
Oh well, I'm off to restart the 4.6 make. Again.
And yet, so familiar. When I leapt into the world of commercial software for the UNIX platform, way back in 1991, we needed a way to level the playing field on the numerous versions of UNIX we were developing for. My product, Security Toolkit/UNIX, was a security analysis package. It was the digital equivalent of the type of security guard known as a 'doorknob rattler', the guy who walks around the warehouse at night making sure the windows are closed and the doors locked. We had a relatively long checklist of settings we would poke into, and rate your systems security posture.
By the time it was a year old, this product ran on Ultrix on MIPS and VAX; SunOS on M68K and SPARC, HP/UX on M68K and HPPA, and AIX on the Power platform. Not long after that the sales people found Data General Aviion, Motorola, and Intel all sold UNIXy systems, and the race was on. By the time I left Security Toolkit/UNIX, as it was becoming Enterprise Security Manager, it was running on 18 different UNIX platforms.
One of the ways we kept the craziness down in this plethora of CPU architectures, UNIX variants, and operating systems quirks was to rely on GCC for compiling and GNU make for building the software. We had a single source code tree that built STK on all of these architectures, and it would have been much harder if we had to code around individual compiler quirks on every platform.
Most of the machines we only had one of. We occasionally got pushed to dual-boot a machine for a more obscure UNIX variant, but we always managed to push back enough to get at least one machine for each system we were required to build on. In many cases (the m68k build for SunOS leaps immediately to mind) it actually took longer to build our standard compliment of GNU tools than it did to port the software and have it working (just over 3 days, vs just under 2; the SunOS/m68k port was done the week before the Christmas party.)
Because disk space was fairly expensive in those days, we generally built the GNU tool chain once for each platform, and exported it via NFS. This became a central part of our strategy; no matter which machine you were logged into, your home directory was mounted (often via automount) on /home/username, and the GNU tools were available in the /tools directory tree. If you had /tools/bin in your path, you were ready to develop, debug, etc.
Upgrades to the compiler were a big event. Our slowest machine, a lowly VAXstation 2000, had almost exactly 1/60th the compile speed of the fastest machine, an early Alpha workstation also from DEC. The Alpha would compile STK in 20 minutes, the VAXstation took 20 hours. The 'product build' process was a script that would rsh to each machine, from fastest to slowest, and start the build process. Upgrading GCC would take half of our 4 developers out of product development for a week, so we only did it when we had a compelling reason. Usually this was fixing bugs in the HPPA or Power code generators, but hey, those architectures made us money so it was worth the pain.
So why am I building GCC for Debian today? We are experimenting with some of the C++11 features, and the default compiler for Debian Squeeze, our base, is 4.4.5. The 4.4 branch doesn't have lambdas, which we are pretty sure we want, so we're going to jump to (probably) 4.6 to get lambda support. The 4.7 build is mostly so we can sanity check it and see how it's coming along, plus it turns out that 4.7 is easier to build with 'current' versions of some of the build prerequisities like gmp, mpc, and mpfr.
This will bring up the inevitable question from the Debian crowd: "Why don't you just install a deb?"
Simple: the Debian "experimental" GCC packages are STOOOOOOOOPID.
Why would anyone want to replace their system compiler with an experimental one? GCC makes it very straightforward to install a second (third, fourth, etc.) compiler version alongside the system one, so why does the Debian experimental package replace the system compiler? The FreeBSD Ports system, always my paragon of how to do things correctly, allows you to install any number of GCC versions side by side; you just run gcc-4.6, gcc-4.7, etc to get the compiler you want.
Oh well, I'm off to restart the 4.6 make. Again.
Comments
Post a Comment