The Debian 2.2 GNU compiler suite setup ======================================= Abstract -------- In Debian 2.2 the default C compiler was changed to gcc-2.95.2. That's basically the unreleased and renamed egcs-1.2 compiler (The egcs steering committee was appointed official GNU maintainer for GCC in April 1999; the egcs team will be responsible for rolling out future GCC releases). The old gcc-2.7.2.3 C compiler is still available for compatibility reasons (compilation of 2.0.xx kernels). At the end you can find a summary of modifications on gcc that Debian has made for it's gcc version. Introduction ------------ Debian 2.2 has two main sets of compiler(related) packages: - One based on gcc-2.95.2 (egcs-1.2). These include the compilers g++, gobjc, g77, chill and gcj and libraries libstdc++2.9(-dev), libg++2.8.1.3(-dev). On all architectures gcc-2.95.2 provides the preferred C compiler which is called `gcc'. - 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 two compiler/library suites? -------------------------------- The rationale for having two compiler/library suites is that they have different strengths and weaknesses: - gcc-2.95.2 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.2 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 . Practical implications ---------------------- The most important practical implications are is 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 ------------- 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. 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 does only have 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.2 package, a Beta version of GNU Pascal 2.2 is included. 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 . =============================================================================== Patches applied in this version: libobjc: Find header file for Boehm garbage collector. 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) libg++-update: 2000-03-12 Manfred Hollstein * Fix.h (Fix::Rep): Move definition into public context. bootstrap: Make bootstrap: restartable at any point From: Donn Terry cpp-macro-doc: cpp.texi: add a node documenting macro varargs. gcc-default-arch: set the default architecture to i386; even if gcc is configured with i386-linux, it builds with Pentium instructions, tuned for i386. gcc-cvs-updates-20000220: CVS updates until Sun Feb 20 15:05:34 MET 2000 of the gcc-2_95-branch (after the gcc-2.95.2 release). libstdc++-out-of-mem: Throw exception instead of aborting when out of memory libstdc++-wstring: enable definition of wstring type, if __ENABLE_WSTRING is defined. libstdc++-wall3: 1999-11-10 Benjamin Kosnik Matthias Klose * stl_rope.h: Fix initialization order. * stl_deque.h: Use static_casts(signed_type). libstdc++-bastring: Here is a patch to /usr/include/g++-2/std/bastring.h which makes it work for me (though note that I have not tested the c_str() method as such): gcc-manpage: Document exit codes. cpp-dos-newlines: Handle DOS newlines after backslashes. Patch from http://www.cygnus.com/ml/egcs/1999-Jan/0784.html gcc-pointer-arith: Wed Sep 1 09:12:02 1999 Jim Kingdon * c-parse.in: save and restore warn_pointer_arith on __extension__ along with pedantic. (SAVE_WARN_FLAGS, RESTORE_WARN_FLAGS): Added. Set the type of extension to itype rather than $1 kludge. * extend.texi (Alternate Keywords): Adjust documentation. gcj-vs-iconv: This patch changes gcj to use iconv(), when available, to read Java source files. It adds a new `--encoding' option that lets the user choose what encoding to use. For systems without iconv(), gcj still assumes that the input is UTF-8, but it no longer ignores encoding errors. This patch does have one minor problem, which is that if --encoding is not specified we default to UTF-8 instead of the encoding the user has chosen (as part of his locale). I don't know how to find that information. Anyway, that is an addition which shouldn't affect whether or not this patch goes in, since this patch doesn't make the situation any worse than it is right now. This fixes PR gcj/33; I can now compile a Latin-1 encoded file on my PPC Linux box with `gcj --encoding=Latin1 ...'. reporting: --help gives hint to /usr/share/doc/debian/bug-reporting.txt gcc-empty-struct-init: Subject: empty struct initializer fix From: Richard Henderson Date: Sun, 20 Feb 2000 00:33:40 -0800 gpc-2.95: The gpc patch from the gpc-19991030 tarball.