C++ compiler situation: draft documentation (feedback appreciated)
I've written a draft for a README to explain the Debian 2.0 compiler setup;
I intend to include this README in the next egcs upload.
I'd appreciate suggestions for improvement.
The Debian 2.0 C / C++ / Objective-C / Fortran77 compiler setup
In Debian 2.0 there is a complex situation with regard to compiler packages;
this note attempts to explain the rationale behind it, the problems it can
cause for the unweary and what to do about them.
Debian 2.0 has two main sets of compiler(related) packages (1):
- one based on / for use with the Experimental GCC Compiler Suite (egcs,
These include the compilers g++, gobjc, g77 and libraries
libstdc++2.8(-dev), libg++2.8(-dev). On some architectures
(e.g. PowerPC and Alpha), egcs provides the preferred C compiler which
is called `gcc'; on others it (x86 and m68k) provides the non-preferred
compiler as `egcc'.
- one based on / for use with the FSF's GNU CC Compiler version 126.96.36.199
This encompasses the `gcc' package on x86 and m68k, libg++272(-dev) and
Why two compiler/library suites?
The rationale for having two compiler/library suites is that they have
different strengths and weaknesses:
- FSF gcc 2.7.2.x provides a reliable C compiler that has been used in the
development of the 2.0.x (stable) series of Linux kernels (from which the
Debian 2.0 default kernel is derived).
The optimisation behaviour of egcs gcc is different and has caused egcs
gcc-compiled 2.0.x kernels not to function properly; therefore we need
an FSF gcc 2.7.2.x C compiler.
- One of the egcs project aims is improving the speed of gcc development.
One of the practical results of that is that the egcs C++ components are
a big improvement compared to the gcc 2.7.2.x one. They contains nearly
all the improvements from gcc 2.8.x (which itself is a big improvement
over 2.7.2.x C++-wise), and further more have an unmodified copy of
SGI's STL (the standard template library) implementation; the C++
runtime libraries are integrated into egcs.
(1) I'm not taking into account the libc5 backwards compatibility
The most important practical implications are:
- invoking a compiler for a different language than C through the
`-x' option of the (e)gcc compiler driver (e.g. `gcc -x c++ foo.cc')
may not produce the intended result.
Instead, Debian now has separate drivers/frontends for the various
languages; you should call the appropriate one:
- `cc' (from the `gcc' or `egcc' packages) for C code.
Use `gcc' or `egcc' only if your code needs explicitly that version
of the C compiler (e.g. for kernel compiles). Be aware that on some
architectures `gcc' is the egcs one!
- `c++' (from the `g++' package) for C++ code.
Use `g++272' for C++ code that does not work with egcs's `g++' package.
- `gobcj' for Objective C code.
- `g77' for Fortran 77 code.
- When combining code generated by different frontends, make sure these
frontends are of the same set. I.e. if you want to combine code
generated by `c++' with C code, use `egcc' to compile the C code rather
Their have been some upstream changes in the C++ libraries that can create
confusion. With gcc 2.7.2.x, there was only one upstream C++ library: libg++
(in Debian: libg++272 and libg++272-dev). This contained both the C++
standard library, a (hacked up?) version of the C++ standard template
library (reflecting the draft version of that available at the time gcc
2.7.2.x was released) and a large number of GNU-specific classes. In the
time between the release of gcc 2.7.2.x and the current egcs version, the
development of the STL proceeded (incorporating a lot of functionality
similar to that in the GNU-specific classes of libg++ 2.7.2.x)) and the
ANSI/ISO C++ draft was extended, refined and finally accepted.
As a result of these developments, with the release of gcc 2.8.0 (i.e. at
the starting point of the egcs project) libg++ was broken up into three parts
- gperf, the perfect hash function generator.
- libstdc++ 2.8.x (in Debian: libstdc++2.8 and libstdc++2.8-dev), containing
only the standard C++ library and the STL.
- libg++ 2.8.x (in Debian: libg++2.8 and libg++2.8-dev), containing only the
GNU-specific classes. As most of the functionality in these is present
in standardised fashion in libstdc++, there will be no further development
of this. If you maintain code that uses the GNU-specific classes, you
are strongly encouraged to move to using the standard classes of
Feedback about this document is appreciated; preferably as a Severity:
wishlist bug against Package: g++ .
PATRIOTISM A great British writer once said that if he had to choose
between betraying his country and betraying a friend he hoped he would
have the decency to betray his country.
- The Hipcrime Vocab by Chad C. Mulligan
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org