366 lines
16 KiB
HTML
366 lines
16 KiB
HTML
<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>
|