[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
  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

Practical implications

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
  than `cc'.

C++ libraries

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
  libstdc++ .

Feedback appreciated

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 debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: