"Linux Gazette...making Linux just a little more fun!"

The GNU gcc compiler is one of the most highly-regarded applications made available by the Free Software Foundation; it has become an integral part of Linux distributions. The existence of gcc and its corollary utilities (make, autoconf, etc.) makes it possible to distribute source code for everything from the Linux kernel itself to a wide variety of free software applications and utilities. This fact is crucial to the survival and health of Linux; different people run different kernels and distributions, and it would be expecting too much to ask volunteer developers to create binary distributions for all of the different flavors and variations of Linux and other Unix-derived operating systems. Richard Stallman does have a valid point when he emphasizes Linux's dependence upon the many GNU utilities.

Lately there has been a flurry of activity in the GNU gcc compiler world, resulting in new releases and giving Linux users expanded choices in their development environments.

The GNU people operate in a relatively closed environment; the average user doesn't have access to news or progress reports; a new release is usually the first indication that development is actually progressing. Since GNU software is released under the GNU licence, there is nothing to stop other developers from modifying the code and making available variant releases. There exists another approach to free software development, in which patches and "snapshot" releases are freely available for interested developers and users. The Linux kernel (with both stable and unstable development releases available) is an obvious and influential example. XEmacs, KDE, and GNOME are others. Since the advent of egcs it seems the GNU developers might be moving toward this development model, judging by some new material at the GNU web-site. Eric Raymonds' online article, The Cathedral and the Bazaar is an insightful and interesting interpretation of these two different models of free software development. This piece was one of the inspirations for the first gcc variant (that I know of) to become available: egcs.

Gcc 2.7.2 has been the standard GNU compiler for some time now. The Cygnus Corporation is a company which offers commercial support for the GNU utilities and has ported many of them to the Windows environment. A group of programmers there decided to try an experiment. Beginning with the stock GNU sources, they adapted the patches which would eventually become gcc-2.8.0 (I assume from the GNU gcc development source tree) and added experimental features which the GNU developers either weren't interested in or were delaying for a future release. The idea was to make periodic snapshot releases freely available with the hope of attracting more developers. This approach seems to be working; I don't know how many new programmers are contributing to the project, but the two releases they have made to date (1.00 and 1.01) are being used by quite a few people without many problems. Any fruitful changes in gcc/egcs will be available to the GNU gcc developers for possible inclusion in future releases. This benefits end-users as well as the GNU programmers, as users get to try these new features and functions (and hopefully bugs will be reported and dealt with), while the sources may be of use to the GNU gcc people in their efforts.

Both the gcc and egcs compilers are intended to be built and used on systems based on a variety of processors. Yet another group of developers has hacked the egcs code to support operations peculiar to the Intel Pentium processors. Pgcc consists of a set of patches which can be applied to the egcs source, which will allow code to be compiled with various pentium optimizations. These developers claim execution speed (of binaries compiled with pgcc) can be five to thirty percent faster than stock gcc. A new Linux distribution called Stampede is using pgcs to compile the binaries of the kernel and applications which they plan to distribute. Interestingly enough, the original patches which the pgcc team used as a starting point came from a programming team at Intel.

Though the GNU gcc compiler has always worked well for me, the appeal of novelty led me to tentatively experiment with egcs when the first real release appeared on the egcs web-site late last year. The first thing I noticed was that the compiler tends to generate more warnings than the -Wall switch did with gcc 2.7.2. These don't seem to have deleterious effects, and I've heard gcc 2.8.0 exhibits the same tendency. Everything I tried seemed to compile successfully except for the KDE source; I've been told that this will be fixed for KDE beta 3. If you've never built a version of gcc from source be prepared for a long, disk-space-intensive compilation. It happens in several stages; during the last of these the compiler actually compiles itself, a process known as boot-strapping.

Some time after installing egcs I happened upon the pgcc web-site. I downloaded a large set of patches and patched the egcs source, ending up with another compiler. Along with the claimed execution speed increase (which in most cases probably isn't large enough to be noticeable) optimization can be increased to -O6, and a pentium-specific flag (-mpentium) can be used. The binaries generated tend to be substantially larger than gcc's due to the default inclusion of exception-handling. This can be disabled with the switch -fno-exceptions.

So far I've compiled several Linux kernels, XEmacs, mutt, slrn, the Gimp, gzip, bzip2, and others without any problems. I wish I was a systematic type of person and had timed the execution of these programs before and after using egcs/pgcc, but I'm not. As an example, I'm running XEmacs 20.5 beta-22 using the Linux kernel 2.1.84, and the editor seems snappier and more responsive than before. But is this due to the compiler, the kernel, the XEmacs version, or (most probably) all three? Too many variables and not enough time!

I wouldn't recommend installing any of these gcc variants unless you are willing to monitor newsgroups, web-sites, and possibly the mailing-lists. Luckily problems and work-arounds are reported quickly, and of course the invaluable safety-net of gcc distribution packages is always there if your set-up gets badly hosed. It will be interesting to see what comes of this non-adversarial fork in the evolution of gcc.

Last modified: Sat 31 Jan 1998