1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
The Debian 2.1 C / C++ / Objective-C / Fortran77 compiler setup
===============================================================
Abstract
--------
In Debian 2.1 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. At the end you can find a
summary of modifications on egcs that Debian has made for it's egcs version.
Introduction
------------
Debian 2.1 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, gpc and libraries
libstdc++2.9(-dev), libg++2.8.2(-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), g++272
and gobjc272.
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.1 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 ones. 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.
[*] If you insist on using egcs gcc, 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:
- 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/front ends 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.
Combining C and C++ code
------------------------
When combining code generated by different front ends, make sure these
front ends 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'. When configuring sources, use
CC=egcc ./configure <configure options> # bash
setenv CC egcc ./configure <options> # csh
When calling make, use `make CC=egcc'.
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.9.x (in Debian: libstdc++2.9 and libstdc++2.9-dev), containing
only the standard C++ library and the STL.
- libg++ 2.8.x (in Debian: libg++2.8.2 and libg++2.8.2-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 egcs-1.1 has to use the libstdc++2.9
libraries. Many programs however are still linked with libstdc++2.8,
which was part of the egcs-1.0.x compilers.
libstdc++ shared object name for glibc-2.0 based systems
--------------------------------------------------------
Debian uses a patch for the libstdc++ library, that installs libstdc++
under a different shared object name, which codes the glibc version
into the shared object name. The rationale for including the patch is
a smooth transition from glibc-2.0 to glibc-2.1 (which is in progress
for various platforms). If binaries which depend on libstdc++ have to
work on other Linux platforms as well, you have several choices:
- Run the script /usr/doc/libstdc++2.9-dev/debian-libstdc++.sh to the
target system, which will make a fake libstdc++.so.2.9 library.
- Include the Debian libstdc++ version into your package.
- Configure the libstdc++-2.9-dev package to use the compatible libstdc++
shared object name. g++ then uses the compatible version of libstdc++,
however you may get problems with a smooth upgrade from glibc-2.0 to
glibc-2.1 for executables linked with the compatible shared object name.
/usr/sbin/libstdc++-dev-config --compatible
/usr/sbin/libstdc++-dev-config --debian
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 or egcs. The ObjC compiler is normally called like the C
compiler (`cc'). Debian/Linux currently has two different ObjC
compilers, gcc 2.7.2 (gobjc272) and egcs 1.1.1 (gobjc), 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 set up 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.
Pascal
------
In the egcs package, a Beta version of GNU Pascal 2.2 is included.
Feedback appreciated
--------------------
Feedback about this document is appreciated; preferably as a Severity:
wishlist bug against Package: g++ .
===============================================================================
|
