The Debian 2.0 C / C++ / Objective-C / Fortran77 compiler setup
===============================================================

Abstract
--------

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 unwary and what to do about them.


Introduction
------------

Debian 2.0 has two main sets of compiler(related) packages:
- one based on / for use with the Experimental GCC Compiler Suite (egcs,
  igate.starpaging.com).
  These include the compilers g++, gobjc, g77 and libraries
  libstdc++2.8(-dev), libg++2.8(-dev).  On the PowerPC and Alpha architectures
  egcs provides the preferred C compiler which is called `gcc'; on x86,
  m68k, and sparc it provides the non-preferred compiler as `egcc'.
- one based on / for use with the FSF's GNU CC Compiler version 2.7.2.3
  (http://www.fsf.org/software/gcc/gcc.html).
  This encompasses the `gcc' package on x86 and m68k, libg++272(-dev) and
  g++272.


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 contain nearly
  all the improvements from gcc 2.8.x (which itself is a big improvement
  over 2.7.2.x C++-wise), and furthermore have an unmodified copy of
  SGI's STL (the standard template library) implementation; the C++
  runtime libraries are integrated into egcs.


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 have a specific need to use that
    particular 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.
  - `cc' or 'egcc', or 'gcc' for Objective C code; see below.
  - `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
-------------

There 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
upstream:
- 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++ .

Objective-C
-----------

The Objective-C runtime changed from gcc version 2.7 to 2.8. ObjC-Code
compiled with gcc 2.7 is not compatible with ObjC-code compiled with
gcc 2.8 or egcs. The ObjC compiler is normally called like the C
compiler (`cc'). Debian/Linux currently has two different ObjC
compilers, gcc 2.7 and egcs 1.0.3a, which have to be called with
different names:

`cc'	- on platforms, where the egcs compiler is the primary compiler
	  (currently only the alpha platform).
`egcc'	- on platforms, where the egcs compiler is the secondary compiler
	  and you want/have to use the newer ObjC runtime (currently the
	  GNUstep packages are setup to use the egcs compiler).
`gcc'	- on platforms, where the egcs compiler is the secondary compiler
	  and you want/have to use the old ObjC runtime.

In any case you have to link your ObjC programs with the thread library
(-lpthread), because ObjC was built to support threads.

Feedback appreciated
--------------------

Feedback about this document is appreciated; preferably as a Severity:
wishlist bug against Package: g++ .
