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
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
|
<html>
<head>
<title>egcs Frequently Asked Questions</title>
</head>
<body bgcolor="white">
<h1 align="center">egcs Frequently Asked Questions</h1>
<ol>
<li><a href="#gcc-2-diff">How is egcs be different from gcc2?</a>
<li><a href="#open-development">What is an open development model?</a>
<li><a href="#libc-lock">bits/libc-lock.h: No such file or directory</a>
<li><a href="#morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a>
<li><a href="#fortran">Problems building the Fortran compiler</a>
<li><a href="#mips">Problems building on MIPS platforms</a>
<li><a href="#x86eh">Problems with exception handling on x86 platforms</a>
<li><a href="#hpcompare">Bootstrap comparison failures on HPs</a>
<li><a href="#makebugs">Bootstrap loops rebuilding cc1 over and over</a>
<li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a>
<li><a href="#rpath">libstdc++/libio tests fail badly with --enable-shared</a>
<li><a href="#dejagnu">Unable to run the testsuite</a>
<li><a href="#cross">How to build a cross compiler</a>
<li><a href="#multiple">How to install both gcc2 and egcs</a>
<li><a href="#snapshot">Snapshots, how, when, why</a>
<li><a href="#linuxkernel">Problems building Linux kernels</a>
<li><a href="#memexhausted">Virtual memory exhausted</a>
<li><a href="#gas">GCC can not find GAS</a>
<li><a href="#rh5.0">egcs does not work on Red Hat 5.0</a>
</ol>
<hr>
<h2><a name="gcc-2-diff">How is egcs be different from gcc2?</a></h2>
<p>Six years ago, gcc version 1 had reached a point of stability. For the
targets it could support, it worked well. It had limitations inherent in
its design that would be difficult to resolve, so a major effort was made
and gcc version 2 was the result. When we had gcc2 in a useful state,
development efforts on gcc1 stopped and we all concentrated on making
gcc2 better than gcc1 could ever be. This is the kind of step forward
we want to make with egcs.
<p>In brief, the three biggest differences between egcs and gcc2 are
these:
<ul>
<li>More rexamination of basic architectual decisions of
gcc and an interest in adding new optimizations;
<li>working with the groups who have fractured out from gcc2 (like
the Linux folks, the Intel optimizations folks, Fortran folks)
including more front-ends; and finally
<li>An open development model (<a
href="#open-development">see below</a>) for the development process.
</ul>
<p>These three differences will work together to result in a more
useful compiler, a more stable compiler, a central compiler that works
for more people, a compiler that generates better code.
<p>There are a lot of exciting compiler optimizations that have come
out. We want them in gcc. There are a lot of front ends out there for
gcc for languages like Fortran or Pascal. We want them easily
installable by users. After six years of working on gcc2, we've come
to see problems and limitations in the way gcc is architected; it is
time to address these again.
<hr>
<h2><a name="open-development">What is an open development model?</a></h2>
<p>With egcs, we are going to try a bazaar style<a
href="#cathedral-vs-bazaar"><b>[1]</b></a> approach to its
development: We're going to be making snapshots publically available
to anyone who wants to try them; we're going to welcome anyone to join
the development mailing list. All of the discussions on the
development mailing list are available via the web. We're going to be
making releases with a much higher frequency than they have been made
in the past: We're shooting for three by the end of 1997.
<p>In addition to weekly snapshots of the egcs development sources, we
are going to look at making the sources readable from a CVS server by
anyone. We want to make it so external maintainers of parts of egcs
are able to commit changes to their part of egcs directly into the
sources without going through an intermediary.
<p>There have been many potential gcc developers who were not able to
participate in gcc development in the past. We these people to help in
any way they can; we ultimately want gcc to be the best compiler in the
world.
<p>A compiler is a complicated piece of software, there will still be
strong central maintainers who will reject patches, who will demand
documentation of implementations, and who will keep the level of
quality as high as it is today. Code that could use wider testing may
be intergrated--code that is simply ill-conceived won't be.
<p>egcs is not the first piece of software to use this open development
process; FreeBSD, the Emacs lisp repository, and Linux are a few
examples of the bazaar style of development.
<p>With egcs, we will be adding new features and optimizations at a
rate that has not been done since the creation of gcc2; these additions
will inevitably have a temporarily destabilizing effect. With the help
of developers working together with this bazaar style development, the
resulting stability and quality levels will be better than we've had
before.
<blockquote>
<a name="cathedral-vs-bazaar"><b>[1]</b></a>
We've been discussing different development models a lot over the
past few months. The paper which started all of this introduced two
terms: A <b>cathedral</b> development model versus a <b>bazaar</b>
development model. The paper is written by Eric S. Raymond, it is
called ``<a
href="http://locke.ccil.org/~esr/writings/cathedral.html">The
Cathedral and the Bazaar</a>''. The paper is a useful starting point
for discussions.
</blockquote>
<hr>
<h2><a name="libc-lock">bits/libc-lock.h: No such file or directory</a></h2>
<p>egcs includes a tightly integrated libio and libstdc++ implementation which
can cause problems on hosts which have libio integrated into their C library
(most notably Linux).
<p>We believe that we've solved the major technical problems for the most
common versions of libc found on Linux systems. However, some versions
of Linux use pre-release versions of glibc2, which egcs has trouble detecting
and correctly handling.
<p>If you're using one of these pre-release versions of glibc2, you may get
a message "bits/libc-lock.h: No such file or directory" when building egcs.
Unfortunately, to fix this problem you will need to update your C library to
glibc2.0.5c.
<p>Late breaking news: we may have at least a partial solution for these
problems. So this FAQ entry may no longer be needed.
<hr>
<h2><a name="morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a></h2>
<p>If you get this error, it means either egcs incorrectly guessed what version
of libc is installed on your linux system, or you incorrectly specified a
version of glibc when configuring egcs.
<p>If you did not provide a target name when configuring egcs, then you've
found a bug which needs to be reported. If you did provide a target name at
configure time, then you should reconfigure without specifying a target name.
<hr>
<h2><a name="fortran">Problems building the Fortran compiler</a></h2>
<p>The Fortran front end can not be built with most vendor compilers; it must
be built with gcc. As a result, you may get an error if you do not follow
the install instructions carefully.
<p>In particular, instead of using "make" to build egcs, you should use
"make bootstrap" if you are building a native compiler or "make cross"
if you are building a cross compiler.
<p>It has also been reported that the Fortran compiler can not be built
on Red Hat 4.X linux for the Alpha. Fixing this may require upgrading
binutils or to Red Hat 5.0; we'll provide more information as it becomes
available.
<hr>
<h2><a name="mips">Problems building on MIPS platforms</a></h2>
<p>egcs requires the use of GAS on all versions of Irix, except Irix 6 due
to limitations in older Irix assemblers.
<p> Either of these messages indicates that you are using the MIPS assembler
when instead you should be using GAS.
<pre>
as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
.4byte $LECIE1-$LSCIE1
as0: Error: ./libgcc2.c, line 1:malformed statement
</pre>
<hr>
<pre>
as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression
.word $LECIE1-$LSCIE1
</pre>
<p> For Irix 6, you should use the native assembler as GAS is not supported
on Irix 6.
<hr>
<h2> <a name="x86eh">Problems with exception handling on x86 platforms</a></h2>
<p>If you are using the GNU assembler (aka gas) on an x86 platform and
exception handling is not working correctly, then odds are you're using a
buggy assembler.
<p>We recommend binutils-2.8.0.1.15 or newer.
<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz"> binutils-2.8.0.1.15 source</a>
<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz"> binutils-2.8.0.1.15 x86 binary for libc5</a>
<br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz"> binutils-2.8.0.1.15 x86 binary for glibc2</a>
Or, you can try a
<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz"> binutils snapshot</a>; however, be aware that the binutils snapshot is untested
and may not work (or even build). Use it at your own risk.
<hr>
<h2> <a name="hpcompare">Bootstrap comparison failures on HPs</a></h2>
<p>If you bootstrap the compiler on hpux10 using the HP assembler instead of
gas, every file will fail the comparison test.
<p>The HP asembler inserts timestamps into object files it creates, causing
every file to be different. The location of the timestamp varies for each
object file, so there's no real way to work around this mis-feature.
<p>Odds are your compiler is fine, but there's no way to be certain.
<p>If you use GAS on HPs, then you will not run into this problem because
GAS never inserts timestamps into object files. For this and various other
reasons we highly recommend using GAS on HPs.
<hr>
<h2> <a name="makebugs">Bootstrap loops rebuilding cc1 over and over</a></h2>
<p>When building egcs, the build process loops rebuilding cc1 over and
over again. This happens on mips-sgi-irix5.2, and possibly other platforms.
<p>This is probably a bug somewhere in the egcs Makefile. Until we find and
fix this bug we recommend you use GNU make instead of vendor supplied make
programs.
<hr>
<h2> <a name="rpath">Dynamic linker is unable to find GCC libraries</a></h2>
<p>This problem manifests itself by programs not finding shared libraries
they depend on when the programs are started. Note this problem often manifests
itself with failures in the libio/libstdc++ tests after configuring with
--enable-shared and building egcs.
<p>GCC does not specify a runpath so that the dynamic linker can find dynamic
libraries at runtime.
<p>The short explaination is that if you always pass a -R option to the
linker, then your programs become dependent on directories which
may be NFS mounted, and programs may hang unnecessarily when an
NFS server goes down.
<p>The problem is not programs that do require the directories; those
programs are going to hang no matter what you do. The problem is
programs that do not require the directories.
<p>SunOS effectively always passed a -R option for every -L option;
this was a bad idea, and so it was removed for Solaris. We should
not recreate it.
<hr>
<h2> <a name="dejagnu">Unable to run the testsuite</a></h2>
<p>If you get a message about unable to find "standard.exp" when trying to
run the egcs testsuites, then your dejagnu is too old to run the egcs tests.
You will need to get a newer version of dejagnu; we've made a
<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz">
dejagnu snapshot</a> available until a new version of dejagnu can be released.
<hr>
<h2> <a name="cross">How to build a cross compiler</a></h2>
<p> Building cross compilers is a rather complex undertaking because they
usually need additional software (cross assembler, cross linker, target
libraries, target include files, etc).
<p> We recommend reading the <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1">
crossgcc FAQ</a> for information about building cross compilers.
<p> If you have all the pieces available, then `make cross' should build a
cross compiler. `make LANGUAGES="c c++" install'will install the cross
compiler.
<p> Note that if you're trying to build a cross compiler in a tree which
includes binutils-2.8 in addition to egcs, then you're going to need to
make a couple minor tweaks so that the cross assembler, linker and
nm utilities will be found.
<p>binutils-2.8 builds those files as gas.new, ld.new and nm.new; egcs gcc
looks for them using gas-new, ld-new and nm-new, so you may have to arrange
for any symlinks which point to <file>.new to be changed to <file>-new.
<hr>
<h2> <a name="snapshot">Snapshots, how, when, why</a></h2>
<p> We make snapshots of the egcs sources about once a week; there is no
predetermined schedule. These snapshots are intended to give everyone
access to work in progress. Any given snapshot may generate incorrect code
or even fail to build.
<p>If you plan on downloading and using snapshots, we highly recommend you
subscribe to the egcs mailing lists. See <a href="index.html#mailinglists">
mailing lists</a> on the main egcs page for instructions on how to subscribe.
<p>When using the diff files to update from older snapshots to newer snapshots,
make sure to use "-E" and "-p" arguments to patch so that empty files are
deleted and full pathnames are provided to patch. If your version of
patch does not support "-E", you'll need to get a newer version. Also note
that you may need autoconf, autoheader and various other programs if you use
diff files to update from one snapshot to the next.
<hr>
<h2> <a name="multiple">How to install both egcs and gcc2</a></h2>
<p>It may be desirable to install both egcs and gcc2 on the same system. This
can be done by using different prefix paths at configure time and a few
symlinks.
<p>Basically, configure the two compilers with different --prefix options,
then build and install each compiler. Assume you want "gcc" to be the egcs
compiler and available in /usr/local/bin; also assume that you want "gcc2"
to be the gcc2 compiler and also available in /usr/local/bin.
<p>The easiest way to do this is to configure egcs with --prefix=/usr/local/egcs
and gcc2 with --prefix=/usr/local/gcc2. Build and install both compilers.
Then make a symlink from /usr/local/bin/gcc to /usr/local/egcs/bin/gcc and
from /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
for the "g++", "c++" and "g77" compiler drivers.
<hr>
<h2> <a name="linuxkernel">Problems building Linux kernels</a></h2>
<p>If you installed a recent binutils/gas snapshot on your Linux system,
you may not be able to build the kernel because objdump does not understand
the "-k" switch. The solution for this problem is to remove /usr/bin/encaps.
<p>You may get an internal compiler error compiling process.c in newer
versions of the Linux kernel on x86 machines. This is a bug in an asm
statement in process.c, not a bug in egcs. XXX How to fix?!?
<p>You may get errors with the X driver of the form
<pre>
_X11TransSocketUNIXConnect: Can't connect: errno = 111
</pre>
<p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/process.c
does an illegal hack which used to work but is now broken since GCC optimizes
more aggressively . The newer 2.1.x kernels already have a fix which should
also work in 2.0.32.
<hr>
<h2> <a name="memexhausted">Virtual memory exhausted error</a></h2>
<p> This error means your system ran out of memory; this can happen for large
files, particularly when optimizing. If you're getting this error you should
consider trying to simplify your files or reducing the optimization level.
<p>Note that using -pedantic or -Wreturn-type can cause an explosion in the
amount of memory needed for template-heavy C++ code, such as code that uses
STL. Also note that -Wall includes -Wreturn-type, so if you use -Wall you
will need to specify -Wno-return-type to turn it off.
<hr>
<h2> <a name="gas">GCC can not find GAS</a></h2>
<p>Some configurations like irix4, irix5, hpux* require the use of the GNU
assembler intead of the system assembler. To ensure that egcs finds the GNU
assembler, you should configure the GNU assembler with the same --prefix
option as you used for egcs. Then build & install the GNU assembler.
<hr>
<h2> <a name="rh5.0">egcs does not work on Red Hat 5.0</a></h2>
<p> egcs does not currently work with Red Hat 5.0; we'll update this
entry with more information as it becomes available.
<hr>
<p><a href="index.html">Return to the egcs home page</a>
<p><i>Last modified: December 2, 1997</i>
</body>
</html>
|
