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 # bash setenv CC gcc272; ./configure # 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. 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 Ray Dassen Philip Blundell (arm-linux) Ben Collins (sparc-linux) Christopher C. Chimelis (alpha-linux) Randolph Chung (ia64-linux) Dan Jacobowitz (powerpc-linux) Matt Taggart (hppa-linux) Gerhard Tonn (s390-linux) Roman Zippel (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 gcj-debian-policy: Comply with the Debian java policy in the java-common package Stephane Bortzmeyer 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 * jatool.c (extract_jar): Account for null termination when determining whether to expand "filename". 2002-01-09 Tom Tromey * 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. libffi-install: Allows libffi to be installed deb-protoize: build protoize/unprotoize by default libobjc: Find header file for Boehm garbage collector. g77-names: versioned g77 names reporting: --help gives hint to /usr/share/doc/debian/bug-reporting.txt