The Debian 3.0 GNU compiler suite setup
=======================================
Abstract
--------
In Debian 3.0, the gcc-3.0 compiler first appeared. This is the next
major release of the FSF GNU compiler suite. This version was released
just before the Debian release freeze, so the gcc-2.95 compiler still
exists for its stability on all major platforms. Also, the gcc
2.7.2.3 C compiler is still available for compatibility reasons (such
as compilation of 2.0.xx kernels).
At the end you can find a summary of modifications on gcc that Debian
has made for its gcc version.
Introduction
------------
Debian 3.0 has three main sets of compiler(related) packages:
- One based on gcc-3.0.x. These include the compilers g++, gobjc, g77,
chill, gcj and libraries libstdc++3, libobjc1, libgcj2 and libgcc1.
On some architectures, this is the preferred C compiler which
is called `gcc' (hppa).
- One based on gcc-2.95. These include the compilers g++, gobjc,
g77, chill and gcj and libraries libstdc++2.9(-dev), libg++2.8.1.3(-dev).
On most architectures gcc-2.95 provides the preferred C compiler which
is called `gcc'.
NOTE for ia64: The default compiler for ia64 is 2.96.
- One based on the FSF's GNU CC Compiler version 2.7.2.3
(http://www.fsf.org/software/gcc/gcc.html). This only encompasses the
package `gcc272'. g++272 and libg++272 do not build from source on our
glibc-2.1.3 based systems anymore. Please get these packages from the
slink distribution (Debian 2.1).
[Other distributions, i.e. Redhat cheat by including a compiled libg++272
binary in the source package].
Why three compiler/library suites?
--------------------------------
The rationale for having two compiler/library suites is that they have
different strengths and weaknesses:
- gcc-3.0 brings a completely ANSI C++ compliant library (v3) with a
stable ABI. Integrated Java compilers, broader architecture support.
- gcc-2.95 brings many improvements over 2.7.2.x and gcc 2.8.x: Much
better ANSI C++ conformance, integrated SGI's STL (the standard template
library) implementation, new compilers for Java and Chill.
- 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.1 default kernel is derived).
The optimisation behaviour of gcc-2.95 is different and has caused
gcc-2.95-compiled 2.0.x kernels not to function properly [*]; therefore
we need an FSF gcc 2.7.2.x C compiler.
[*] If you insist on using egcs gcc-2.9x, gcc 2.8.1 or PGCC for compiling
2.0.x kernels, you can find patches for the problems that have been found
so far at http://www.suse.de/~florian/kernel+egcs.html .
How are the default compilers selected?
---------------------------------------
Starting in Debian 3.0, there is now a gcc-defaults package set. This
creates the actual packages for gcc, gpc, g++, gobjc, chill, g77 and gcj.
These packages will depend on the corresponding default compiler for that
architecture. For example, on i386, "gcc" depends on "gcc-2.95", which
means that the "gcc-2.95" package will install a binary called "gcc-2.95",
which is symlinked to in the "gcc" package as "gcc".
This may seem confusing, but what it allows you do to is install two
versions of the GCC compiler suite at the same time, making sure you are
always using the one preferred for that architecture. To use the other
compiler, simply set CC=gcc-3.0, or similar.
With this method, each architecture can choose its own preferred compiler,
and that preference can change without requiring a complete rebuild of both
compiler packages for all architectures. (to change the names), and simply
requires updating the small gcc-defaults package set, to point the symlinks
correctly.
Practical implications
----------------------
The most important practical implications are in the merging/linking
of object files built with different compilers; If you use the 2.7.2.x
C compiler, you should use the `gcc272' compiler driver for all your work.
When configuring sources, use
CC=gcc272 ./configure <configure options> # bash
setenv CC gcc272; ./configure <options># csh
When calling make, use `make CC=gcc272'.
To compile a 2.0.xx kernel the gcc272 package should be used. If you use
the Debianized kernel source (package kernel-source-2.0.38), then gcc272
is used by default. If you compile upstream source, make sure to use gcc272
in the toplevel makefile.
C++ libraries
-------------
Some notes on porting applications from libstdc++-2.90 (or earlier versions)
to libstdc++-v3 can be found in the libstdc++3-doc package. After the
installation of the package, look at:
/usr/share/doc/gcc-3.0-base/libstdc++/html/17_intro/porting-howto.html
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 older Debian releases: 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.10 (in Debian: libstdc++2.10 and libstdc++2.10-dev), containing
only the standard C++ library and the STL.
- libg++ 2.8.x (in Debian: libg++2.8.1.3 and libg++2.8.1.3-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++ .
Code compiled with gcc-2.95.2 has to use the libstdc++2.10 libraries. Many
programs however are still linked with libstdc++2.8, which was part of
the egcs-1.0.x compilers.
Now, with the gcc-3.0 compiler, we also have the libstdc++3 libraries,
deprecating the libg++ libraries all together, and bring a stable ABI to
GCC's C++ interface. Also, 2.95 and prior always had a libgcc.a library
that was linked to by all applications that gcc built. This has now been
made available as a shared library, libgcc_s.so, which is in the libgcc1
package.
To use the libstdc++ library (found in the libstd++<N>-dbg package) for
debugging, add /usr/lib/debug to your LD_LIBRARY_PATH. For gdb to display
the source you need to get the correspondig gcc-X.Y source package, unpack
the source and point gdb to the location of the source (`dir' directive).
Java
----
gcj currently has no documentation besides the online documentation found at
http://sourceware.cygnus.com/java/
To compile a simple Hello World program:
gcj --main=HelloWorld -o HelloWorld HelloWorld.java
Objective-C
-----------
The Objective-C runtime changed from gcc version 2.7 to 2.8. ObjC-Code
compiled with gcc 2.7.2 is not compatible with ObjC-code compiled with
gcc 2.8, egcs or gcc-2.95.2. The ObjC compiler is normally called like the C
compiler (`cc'). Debian/Linux only has the ObjC compiler from the
2.95.2 code base.
You have to link your ObjC programs with the thread library
(-lpthread), because ObjC was built to support threads.
Pascal
------
In the gcc-2.95 packages, a Beta version of GNU Pascal 2.2 is included.
Curently gpc doesn't build with gcc-3.0.
Bugs
----
Before submitting a bug, please read README.Bugs in this directory.
Feedback appreciated
--------------------
Feedback about this document is appreciated; preferably as a Severity:
wishlist bug against Package: gcc-3.0 . For general discussions and
questions, subscribe and/or email the debian-gcc@lists.debian.org mailing
list.
Maintainers of these packages
-----------------------------
Matthias Klose <doko@debian.org>
Ray Dassen <jdassen@debian.org>
Philip Blundell <pb@debian.org>(arm-linux)
Ben Collins <bcollins@debian.org>(sparc-linux)
Christopher C. Chimelis <chris@debian.org>(alpha-linux)
Randolph Chung <tausq@debian.org>(ia64-linux)
Dan Jacobowitz <dan@debian.org>(powerpc-linux)
Matt Taggart <taggart@carmen.fc.hp.com>(hppa-linux)
Gerhard Tonn <GerhardTonn@swol.de>(s390-linux)
Roman Zippel <zippel@linux-m68k.org>(m68k-linux)
===============================================================================
Patches applied in this version:
gcc-names:
versioned gcc names
gcc-version:
g++-cxa-atexit:
enable -fuse-cxa-atexit by default.
libstdc++-codecvt:
libstdc++-v3/include/bits/codecvt.h: add missing qualifiers
libstdc++-doxygen:
hrefs to local documentation
PR3145:
This patch is a quick backport of Nathan Sidwell's patch to fix PR c++/3145,
the infamous "virtual inheritance" bug. This affected especially KDE2
(eg. artsd).
Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
gcj-debian-policy:
Comply with the Debian java policy in the java-common package
Stephane Bortzmeyer <bortzmeyer@debian.org>
search gcj.jar in /usr/share/java (doko@cs.tu-berlin.de)
gcj-names:
versioned gcc names
fastjar-build:
build grepjar as well.
java-manpages:
generate and install man pages for java tools
gcj-without-rpath:
don't define runtime link path for java binaries and libraries
fastjar:
2001-10-12 Bryce McKinlay <bryce@waitaki.otago.ac.nz>
* jatool.c (extract_jar): Account for null termination when determining
whether to expand "filename".
2002-01-09 Tom Tromey <tromey@redhat.com>
* Fail if `-u' specified.
jv-convert:
2002-01-09 tromey@gcc.gnu.org
For PR libgcj/5303:
* gnu/gcj/convert/Convert.java (error): Program is called
`jv-convert'. Print GNU-style message. Exit with status 1, not -1.
(main): Handle --help and --version.
(help): New method.
(version): Likewise.
system-zlib:
Link fastjar and libjava with system zlib.
libgcj-date:
Fix Serialization of the java.util.Date class
backport-java-6865:
2002-06-09 Tom Tromey <tromey@redhat.com>
* parse.y (method_header): Give error message in all cases.
Fixes PR java/6865.
objc-testsuite:
Run objc tests with -lpthread.
libobjc:
Find header file for Boehm garbage collector.
g77-names:
versioned g77 names
g77-big-array:
2001-10-22 Toon Moene <toon@moene.indiv.nluug.nl>
* com.c (ffecom_check_size_overflow_): Only check for TREE_OVERFLOW.
2002-03-23 Toon Moene <toon@moene.indiv.nluug.nl>
* com.c (ffecom_check_size_overflow_): Add a test
so that arrays too large for 32-bit byte-offset
addressing get caught.
reporting:
<compiler> --help gives hint to /usr/share/doc/debian/bug-reporting.txt