1131 lines
51 KiB
Plaintext
1131 lines
51 KiB
Plaintext
|
|
GCC Frequently Asked Questions
|
|
|
|
The latest version of this document is always available at
|
|
[1]http://www.gnu.org/software/gcc/faq.html.
|
|
|
|
This FAQ tries to answer specific questions concerning GCC. For
|
|
general information regarding C, C++, resp. Fortran please check the
|
|
[2]comp.lang.c FAQ, [3]comp.lang.c++ FAQ, [4]comp.std.c++ FAQ, and the
|
|
[5]Fortran Information page.
|
|
_________________________________________________________________
|
|
|
|
Questions
|
|
|
|
1. [6]General information
|
|
1. [7]What is the relationship between GCC and EGCS
|
|
2. [8]What is the relationship between GCC and Cygnus
|
|
3. [9]What is an open development model?
|
|
4. [10]How to report bugs
|
|
5. [11]How do I get a bug fixed or a feature added?
|
|
2. [12]Installation
|
|
1. [13]Problems building the Fortran compiler
|
|
2. [14]How to install multiple versions of GCC
|
|
3. [15]Dynamic linker is unable to find GCC libraries
|
|
4. [16]libstdc++/libio tests fail badly with --enable-shared
|
|
5. [17]GCC can not find GNU as/GNU ld
|
|
6. [18]cpp: Usage:... Error
|
|
3. [19]Testsuite problems
|
|
1. [20]Why is there no testsuite in GCC 2.95
|
|
2. [21]Unable to run the testsuite
|
|
3. [22]How do I pass flags like -fnew-abi to the testsuite?
|
|
4. [23]How can I run the test suite with multiple options?
|
|
4. [24]Platform-specific issues
|
|
1. [25]Problems with exception handling on x86 platforms
|
|
2. [26]Problems with Invalid `asm' statements
|
|
3. [27]Building Linux kernels
|
|
4. [28]How do I compile X11 headers with g++
|
|
5. [29]How to build a cross compiler
|
|
5. [30]Bugs and Non-Bugs
|
|
1. [31]FD_ZERO macro
|
|
2. [32]Octave 2.0.13 does not compile
|
|
3. [33]Why can't I initialize a static variable with stdin?
|
|
4. [34]Why can't I use #if here?
|
|
6. [35]Miscellaneous
|
|
1. [36]Virtual memory exhausted
|
|
2. [37]Snapshots, how, when, why
|
|
3. [38]Friend Templates
|
|
4. [39]Where to find libg++
|
|
5. [40]Why do I need autoconf, bison, xgettext, automake, etc
|
|
6. [41]Problems debugging GCC code
|
|
7. [42]Conflicts when using cvs update
|
|
8. [43]Using GCC with GNAT/Ada
|
|
9. [44]Using GCC with GNU Pascal
|
|
10. [45]Using CVS to download snapshots
|
|
11. [46]Why can't I build a shared library?
|
|
12. [47]Dealing with spam on the lists
|
|
13. [48]How to work around too long C++ symbol names?
|
|
(-fsquangle)
|
|
14. [49]When building from CVS sources, I see 'gperf: invalid
|
|
option -- F', even with the most current version of gperf.
|
|
15. [50]When building C++, the linker says my constructors,
|
|
destructors or virtual tables are undefined, but I defined
|
|
them
|
|
16. [51]What is libstdc++-v3 and how can I use it with g++?
|
|
_________________________________________________________________
|
|
|
|
General information
|
|
|
|
What is the relationship between GCC and EGCS
|
|
|
|
In 1990/1991 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 to resolve those limitiations 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 wanted to make with the
|
|
EGCS project when it was formed in 1997.
|
|
|
|
In April 1999 the Free Software Foundation officially halted
|
|
development on the gcc2 compiler and appointed the EGCS project as the
|
|
official GCC maintainers.
|
|
|
|
We are in the process of merging GCC and EGCS, which will take some
|
|
time. The net result will be a single project which will carry forward
|
|
GCC development under the ultimate control of the [52]GCC Steering
|
|
Committee.
|
|
_________________________________________________________________
|
|
|
|
What is the relationship between GCC and Cygnus
|
|
|
|
It is a common mis-conception that Cygnus controls either directly or
|
|
indirectly GCC.
|
|
|
|
While Cygnus does donate hardware, network connections, code and
|
|
developer time to GCC development, Cygnus does not control GCC.
|
|
|
|
Overall control of GCC is in the hands of the [53]GCC Steering
|
|
Committee which includes people from a variety of different
|
|
organizations and backgrounds. The purpose of the steering committee
|
|
is to make decisions in the best interest of GCC and to help ensure
|
|
that no individual or company has control over the project.
|
|
|
|
To summarize, Cygnus contributes to GCCproject, but does not exert a
|
|
controlling influence over GCC.
|
|
_________________________________________________________________
|
|
|
|
What is an open development model?
|
|
|
|
With GCC, we are going to try a bazaar style[54][1] approach to its
|
|
development: We make snapshots publicly 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.
|
|
|
|
In addition to weekly snapshots of the GCC development sources, we
|
|
have the sources readable from a CVS server by anyone. Furthermore we
|
|
are using remote CVS to allow remote maintainers write access to the
|
|
sources.
|
|
|
|
There have been many potential gcc developers who were not able to
|
|
participate in gcc development in the past. We want these people to
|
|
help in any way they can; we ultimately want GCC to be the best
|
|
compiler in the world.
|
|
|
|
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 integrated--code that is simply ill-conceived won't be.
|
|
|
|
GCC is not the first piece of software to use this open development
|
|
process; FreeBSD, the Emacs lisp repository, and the Linux kernel are
|
|
a few examples of the bazaar style of development.
|
|
|
|
With GCC, 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.
|
|
|
|
_[1]_ 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 _cathedral_ development model versus a _bazaar_
|
|
development model. The paper is written by Eric S. Raymond, it is
|
|
called ``[55]The Cathedral and the Bazaar''. The paper is a useful
|
|
starting point for discussions.
|
|
_________________________________________________________________
|
|
|
|
How to report bugs
|
|
|
|
There are complete instructions in the [56]gcc info manual, section
|
|
Bugs. The manual can also be read using `_M-x info_' in Emacs, or if
|
|
the GNU info program is installed on your system by `info --node
|
|
"(gcc)Bugs"'. Or see the file [57]BUGS included with the GCC source
|
|
code.
|
|
|
|
Before you report a bug for the _C++ compiler_, please check the
|
|
[58]list of well-known bugs. If you want to report a bug with _egcs
|
|
1.0.x_ or _egcs 1.1.x_, we strongly recommend upgrading to the current
|
|
release first.
|
|
|
|
In short, if GCC says Internal compiler error (or any other error that
|
|
you'd like us to be able to reproduce, for that matter), please mail a
|
|
bug report to [59]gcc-bugs@gcc.gnu.org or [60]bug-gcc@gnu.org
|
|
including:
|
|
* The GCC version
|
|
* The system type
|
|
* All options you passed to the compiler
|
|
* Preprocessed output of the source file that caused the compiler
|
|
error
|
|
|
|
All this can normally be accomplished by mailing the command line, the
|
|
output of the command, and the resulting `_your-file_.i' for C, or
|
|
`_your-file_.ii' for C++, corresponding to:
|
|
|
|
gcc -v --save-temps _all-your-options_ _your-file_.c
|
|
|
|
Typically the CPP output (extension .i for C or .ii for C++) will be
|
|
large, so please compress the resulting file with one of the popular
|
|
compression programs such as bzip2, gzip, zip, pkzip or compress (in
|
|
decreasing order of preference). Use maximum compression (-9) if
|
|
available. Please include the compressed CPP output in your bug
|
|
report.
|
|
|
|
Since we're supposed to be able to re-create the assembly output
|
|
(extension .s), you usually don't have to include it in the bug
|
|
report, although you may want to post parts of it to point out
|
|
assembly code you consider to be wrong.
|
|
|
|
Whether to use MIME attachments or uuencode is up to you. In any case,
|
|
make sure the compiler command line, version and error output are in
|
|
plain text, so that we don't have to decode the bug report in order to
|
|
tell who should take care of it. A meaningful subject indicating
|
|
language and platform also helps.
|
|
|
|
The gcc lists have message size limits (100 kbytes) and bug reports
|
|
over those limits will currently be bounced. We're trying to find a
|
|
way to allow larger bug reports to be posted, but this is currently
|
|
impossible (unless you use MIME partials, which most people are unable
|
|
to handle anyway, so you'd better avoid them for now). So, although we
|
|
prefer to have complete bug reports archived, if you cannot reduce the
|
|
bug report below the limit, please make it available for ftp or http
|
|
and post the URL. Another alternative is to break the preprocessed
|
|
output in multiple files (using split, for example) and post them in
|
|
separate messages, but we prefer to have self-contained bug reports in
|
|
single messages.
|
|
|
|
If you fail to supply enough information for a bug report to be
|
|
reproduced, someone will probably ask you to post additional
|
|
information (or just ignore your bug report, if they're in a bad day,
|
|
so try to get it right on the first posting :-). In this case, please
|
|
post the additional information to the bug reporting mailing list, not
|
|
just to the person who requested it, unless explicitly told so. If
|
|
possible, please include in this follow-up all the information you had
|
|
supplied in the incomplete bug report (including the preprocessor
|
|
output), so that the new bug report is self-contained.
|
|
_________________________________________________________________
|
|
|
|
How do I get a bug fixed or a feature added?
|
|
|
|
There are lots of ways to get something fixed. The list below may be
|
|
incomplete, but it covers many of the common cases. These are listed
|
|
roughly in order of increasing difficulty for the average GCC user,
|
|
meaning someone who is not skilled in the internals of GCC, and where
|
|
difficulty is measured in terms of the time required to fix the bug.
|
|
No alternative is better than any other; each has it's benefits and
|
|
disadvantages.
|
|
* Hire someone to fix it for you. There are various companies and
|
|
individuals providing support for GCC. This alternative costs
|
|
money, but is relatively likely to get results.
|
|
* Report the problem to gcc-bugs and hope that someone will be kind
|
|
enough to fix it for you. While this is certainly possible, and
|
|
often happens, there is no guarantee that it will. You should not
|
|
expect the same response from gcc-bugs that you would see from a
|
|
commercial support organization since the people who read
|
|
gcc-bugs, if they choose to help you, will be volunteering their
|
|
time. This alternative will work best if you follow the directions
|
|
on [61]submitting bugreports.
|
|
* Fix it yourself. This alternative will probably bring results, if
|
|
you work hard enough, but will probably take a lot of time, and,
|
|
depending on the quality of your work and the perceived benefits
|
|
of your changes, your code may or may not ever make it into an
|
|
official release of GCC.
|
|
_________________________________________________________________
|
|
|
|
Installation
|
|
|
|
Problems building the Fortran compiler
|
|
|
|
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.
|
|
|
|
In particular, instead of using "make" to build GCC, you should use
|
|
"make bootstrap" if you are building a native compiler or "make cross"
|
|
if you are building a cross compiler.
|
|
|
|
It has also been reported that the Fortran compiler can not be built
|
|
on Red Hat 4.X GNU/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.
|
|
_________________________________________________________________
|
|
|
|
How to install multiple versions of gcc
|
|
|
|
It may be desirable to install multiple versions of the compiler on
|
|
the same system. This can be done by using different prefix paths at
|
|
configure time and a few symlinks.
|
|
|
|
Basically, configure the two compilers with different --prefix
|
|
options, then build and install each compiler. Assume you want "gcc"
|
|
to be the latest compiler and available in /usr/local/bin; also assume
|
|
that you want "gcc2" to be the older gcc2 compiler and also available
|
|
in /usr/local/bin.
|
|
|
|
The easiest way to do this is to configure the new GCC with
|
|
--prefix=/usr/local/gcc and the older gcc2 with
|
|
--prefix=/usr/local/gcc2. Build and install both compilers. Then make
|
|
a symlink from /usr/local/bin/gcc to /usr/local/gcc/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.
|
|
|
|
An alternative to using symlinks is to configure with a
|
|
--program-transform-name option. This option specifies a sed command
|
|
to process installed program names with. Using it you can, for
|
|
instance, have all the new GCC programs installed as "new-gcc" and the
|
|
like. You will still have to specify different --prefix options for
|
|
new GCC and old GCC, because it is only the executable program names
|
|
that are transformed. The difference is that you (as administrator) do
|
|
not have to set up symlinks, but must specify additional directories
|
|
in your (as a user) PATH. A complication with --program-transform-name
|
|
is that the sed command invariably contains characters significant to
|
|
the shell, and these have to be escaped correctly, also it is not
|
|
possible to use "^" or "$" in the command. Here is the option to
|
|
prefix "new-" to the new GCC installed programs
|
|
"--program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'". With the above
|
|
--prefix option, that will install the new GCC programs into
|
|
/usr/local/gcc/bin with names prefixed by "new-". You can use
|
|
--program-transform-name if you have multiple versions of GCC, and
|
|
wish to be sure about which version you are invoking.
|
|
|
|
If you use --prefix, GCC may have difficulty locating a GNU assembler
|
|
or linker on your system, [62]GCC can not find GNU as/GNU ld explains
|
|
how to deal with this.
|
|
_________________________________________________________________
|
|
|
|
Dynamic linker is unable to find GCC libraries
|
|
|
|
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 GCC.
|
|
|
|
GCC does not specify a runpath so that the dynamic linker can find
|
|
dynamic libraries at runtime.
|
|
|
|
The short explanation 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
However, if you feel you really need such an option to be passed
|
|
automatically to the linker, you may add it to the gcc specs file.
|
|
This file can be found in the same directory that contains cc1 (run
|
|
gcc -print-prog-name=cc1 to find it). You may add linker flags such as
|
|
-R or -rpath, depending on platform and linker, to the *link or *lib
|
|
specs.
|
|
|
|
Another alterative is to install a wrapper script around gcc, g++ or
|
|
ld that adds the appropriate directory to the environment variable
|
|
LD_RUN_PATH or equivalent (again, it's platform-dependent).
|
|
|
|
Yet another option, that works on a few platforms, is to hard-code the
|
|
full pathname of the library into its soname. This can only be
|
|
accomplished by modifying the appropriate .ml file within
|
|
libstdc++/config (and also libg++/config, if you are building libg++),
|
|
so that $(libdir)/ appears just before the library name in -soname or
|
|
-h options.
|
|
_________________________________________________________________
|
|
|
|
GCC can not find GNU as/GNU ld
|
|
|
|
GCC searches the PATH for an assembler and a loader, but it only does
|
|
so after searching a directory list hard-coded in the gcc executables.
|
|
Since, on most platforms, the hard-coded list includes directories in
|
|
which the system asembler and loader can be found, you may have to
|
|
take one of the following actions to arrange that gcc uses the GNU
|
|
versions of those programs.
|
|
|
|
To ensure that GCC finds the GNU assembler (the GNU loader), which are
|
|
required by [63]some configurations, you should configure these with
|
|
the same --prefix option as you used for GCC. Then build & install GNU
|
|
as (GNU ld) and proceed with building GCC.
|
|
|
|
Another alternative is to create links to GNU as and ld in any of the
|
|
directories printed by the command `gcc -print-search-dirs | grep
|
|
'^programs:''. The link to `ld' should be named `real-ld' if `ld'
|
|
already exists. If such links do not exist while you're compiling GCC,
|
|
you may have to create them in the build directories too, within the
|
|
gcc directory _and_ in all the gcc/stage* subdirectories.
|
|
|
|
GCC 2.95 allows you to specify the full pathname of the assembler and
|
|
the linker to use. The configure flags are `--with-as=/path/to/as' and
|
|
`--with-ld=/path/to/ld'. GCC will try to use these pathnames before
|
|
looking for `as' or `(real-)ld' in the standard search dirs. If, at
|
|
configure-time, the specified programs are found to be GNU utilities,
|
|
`--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will
|
|
be auto-detected. One drawback of this option is that it won't allow
|
|
you to override the search path for assembler and linker with
|
|
command-line options -B/path/ if the specified filenames exist.
|
|
_________________________________________________________________
|
|
|
|
cpp: Usage:... Error
|
|
|
|
If you get an error like this when building GCC (particularly when
|
|
building __mulsi3), then you likely have a problem with your
|
|
environment variables.
|
|
cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
|
|
[switches] input output
|
|
|
|
First look for an explicit '.' in either LIBRARY_PATH or
|
|
GCC_EXEC_PREFIX from your environment. If you do not find an explicit
|
|
'.', look for an empty pathname in those variables. Note that ':' at
|
|
either the start or end of these variables is an implicit '.' and will
|
|
cause problems.
|
|
|
|
Also note '::' in these paths will also cause similar problems.
|
|
_________________________________________________________________
|
|
|
|
Testsuite problems
|
|
|
|
Why is there no testsuite in GCC 2.95
|
|
|
|
The GCC testsuite is not included in the GCC 2.95 release due to the
|
|
uncertain copyright status of some tests.
|
|
|
|
The GCC team will be reviewing the entire testsuite to find and remove
|
|
any tests with uncertain copyright status. Once those tests are
|
|
removed from the testsuite, the testsuite as a whole will be
|
|
copyrighted under the terms of the GPL and included in future GCC
|
|
releases.
|
|
|
|
It is believed that only a few tests have uncertain copyright status
|
|
and thus only a few tests will need to be removed from the testsuite.
|
|
_________________________________________________________________
|
|
|
|
Unable to run the testsuite
|
|
|
|
If you get a message about unable to find "standard.exp" when trying
|
|
to run the GCC testsuites, then your dejagnu is too old to run the GCC
|
|
tests. You will need to get a newer version of dejagnu; we've made a
|
|
[64]dejagnu snapshot available until a new version of dejagnu can be
|
|
released.
|
|
_________________________________________________________________
|
|
|
|
How do I pass flags like -fnew-abi to the testsuite?
|
|
|
|
If you invoke runtest directly, you can use the --tool_opts option,
|
|
e.g:
|
|
runtest --tool_opts "-fnew-abi -fno-honor-std" <other options>
|
|
|
|
Or, if you use make check you can use the make variable RUNTESTFLAGS,
|
|
e.g:
|
|
make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++
|
|
_________________________________________________________________
|
|
|
|
How can I run the test suite with multiple options?
|
|
|
|
If you invoke runtest directly, you can use the --target_board option,
|
|
e.g:
|
|
runtest --target_board "unix{-fPIC,-fpic,}" <other options>
|
|
|
|
Or, if you use make check you can use the make variable RUNTESTFLAGS,
|
|
e.g:
|
|
make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gcc
|
|
|
|
Either of these examples will run the tests three times. Once with
|
|
-fPIC, once with -fpic, and once with no additional flags.
|
|
|
|
This technique is particularly useful on multilibbed targets.
|
|
_________________________________________________________________
|
|
|
|
Platform-specific issues
|
|
|
|
Please read the [65]host/target specific installation notes, too.
|
|
|
|
Problems with exception handling on x86 platforms
|
|
|
|
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. Releases of binutils prior to 2.9 are known
|
|
to assemble exception handling code incorrectly.
|
|
|
|
We recommend binutils-2.9.1 or newer. Some post-2.9.1 snapshots of
|
|
binutils fix some subtle bugs, particularly on x86 and alpha. They are
|
|
available at [66]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/. The
|
|
2.9.1.0.15 snapshot is known to work fine on those platforms; other
|
|
than that, be aware that snapshots are in general untested and may not
|
|
work (or even build). Use them at your own risk.
|
|
_________________________________________________________________
|
|
|
|
Problems with invalid `asm' statements
|
|
|
|
Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) did
|
|
not detect as invalid a clobber specifier that clobbered an operand.
|
|
Instead, it could spuriously and silently generate incorrect code for
|
|
certain non-obvious cases of source code. Even more unfortunately, the
|
|
manual (Using and Porting GCC, section Extended Asm, see the [67]bug
|
|
report entry) did not explicitly say that it was invalid to specify
|
|
clobber registers that were destined to overlap operands; it could
|
|
arguably be interpreted that it was correct to clobber an input
|
|
operand to mark it as not holding a usable value after the asm.
|
|
|
|
For the general case, there is no way to tell whether a specified
|
|
clobber is _intended_ to overlap with a specific (input) operand or is
|
|
a program error, where the choice of actual register for operands
|
|
failed to _avoid_ the clobbered register. Such unavoidable overlap is
|
|
detected by versions GCC 2.95 and newer, and flagged as an error
|
|
rather than accepted. An error message is given, such as:
|
|
foo.c: In function `foo':
|
|
foo.c:7: Invalid `asm' statement:
|
|
foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG.
|
|
|
|
Unfortunately, a lot of existing software, for example the [68]Linux
|
|
kernel version 2.0.35 for the Intel x86, has constructs where input
|
|
operands are marked as clobbered.
|
|
|
|
The manual now describes how to write constructs with operands that
|
|
are modified by the construct, but not actually used. To write an asm
|
|
which modifies an input operand but does not output anything usable,
|
|
specify that operand as an _output operand_ outputting to an _unused
|
|
dummy variable_.
|
|
|
|
In the following example for the x86 architecture (taken from the
|
|
Linux 2.0.35 kernel -- include/asm-i386/delay.h), the register-class
|
|
constraint "a" denotes a register class containing the single register
|
|
"ax" (aka. "eax"). It is therefore invalid to clobber "ax"; this
|
|
operand has to be specified as an output as well as an input. The
|
|
following code is therefore _invalid_:
|
|
extern __inline__ void
|
|
__delay (int loops)
|
|
{
|
|
__asm__ __volatile__
|
|
(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
|
|
: /* no outputs */
|
|
: "a" (loops)
|
|
: "ax");
|
|
}
|
|
|
|
It could be argued that since the register class for "a" contains only
|
|
a single register, this could be detected as an "obvious" intended
|
|
clobber of the input operand. While that is feasible, it opens up for
|
|
further "obvious" cases, where the level of obviousness changes from
|
|
person to person. As there is a correct way to write such asm
|
|
constructs, this obviousness-detection is not needed other than for
|
|
reasons of compatibility with an existing code-base, and that code
|
|
base can be corrected.
|
|
|
|
This corrected and clobber-less version, is _valid_ for GCC 2.95 as
|
|
well as for previous versions of GCC and EGCS:
|
|
extern __inline__ void
|
|
__delay (int loops)
|
|
{
|
|
int dummy;
|
|
|
|
__asm__ __volatile__
|
|
(".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
|
|
: "=a" (dummy)
|
|
: "0" (loops));
|
|
}
|
|
|
|
Note that the asm construct now has an output operand, but it is
|
|
unused. Normally asm constructs with only unused output operands may
|
|
be removed by gcc, unless marked volatile as above.
|
|
_________________________________________________________________
|
|
|
|
Building Linux kernels
|
|
|
|
The linux kernel violates certain aliasing rules specified in the
|
|
ANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer by
|
|
default relies on these rules to produce more efficient code and thus
|
|
will produce malfunctioning kernels. To work around this problem, the
|
|
flag -fno-strict-aliasing must be added to the CFLAGS variable in the
|
|
main kernel Makefile.
|
|
|
|
If you try to build a 2.0.x kernel for Intel machines with any
|
|
compiler other than GCC 2.7.2, then you are on your own. The 2.0.x
|
|
kernels are to be built only with gcc 2.7.2. They use certain asm
|
|
constructs which are incorrect, but (by accident) happen to work with
|
|
gcc 2.7.2. If you insist on building 2.0.x kernels with egcs, you may
|
|
be interested in this [69]patch which fixes some of the asm problems.
|
|
You will also want to change asm constructs to [70]avoid clobbering
|
|
their input operands.
|
|
|
|
If you installed a recent binutils/gas snapshot on your GNU/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. (This is an obsolete program that was part of
|
|
older binutils distributions; the Linux kernel's Makefile looks for
|
|
this program to decide if you have an old or a new binutils. Problems
|
|
occur if you installed a new binutils but haven't removed encaps,
|
|
because the Makefile thinks you have the old one.)
|
|
|
|
Finally, you may get errors with the X driver of the form
|
|
_X11TransSocketUNIXConnect: Can't connect: errno = 111
|
|
|
|
This is a kernel bug. The function sys_iopl in
|
|
arch/i386/kernel/ioport.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.
|
|
_________________________________________________________________
|
|
|
|
How do I compile X11 headers with g++
|
|
|
|
When compiling X11 headers with a GCC 2.95 or newer, g++ will complain
|
|
that types are missing. These headers assume that omitting the type
|
|
means 'int'; this assumption is wrong for C++.
|
|
|
|
g++ accepts such (illegal) constructs with the option -fpermissive; it
|
|
will assume that missing type is 'int' (as defined by the C89
|
|
standard).
|
|
|
|
Since the upcoming C99 standard also obsoletes the implicit type
|
|
assumptions, the X11 headers have to get fixed eventually.
|
|
_________________________________________________________________
|
|
|
|
How to build a cross compiler
|
|
|
|
Building cross compilers is a rather complex undertaking because they
|
|
usually need additional software (cross assembler, cross linker,
|
|
target libraries, target include files, etc).
|
|
|
|
We recommend reading the [71]crossgcc FAQ for information about
|
|
building cross compilers.
|
|
|
|
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.
|
|
|
|
Note that if you're trying to build a cross compiler in a tree which
|
|
includes binutils-2.8 in addition to GCC, then you're going to need to
|
|
make a couple minor tweaks so that the cross assembler, linker and nm
|
|
utilities will be found.
|
|
|
|
binutils-2.8 builds those files as gas.new, ld.new and nm.new; 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.
|
|
_________________________________________________________________
|
|
|
|
Bugs and Non-Bugs
|
|
|
|
Unfortunately, improvements in tools that are widely used are sooner
|
|
or later bound to break _something_. Sometimes, the code that breaks
|
|
was wrong, and then that code should be fixed, even if it works for
|
|
earlier versions of gcc or other compilers. The following problems
|
|
with some releases of widely used packages have been identified:
|
|
|
|
There is a separate [72]list of well-known bugs describing known
|
|
deficiencies. Naturally we'd like that list to be of zero length.
|
|
|
|
To report a bug, see [73]How to report bugs.
|
|
_________________________________________________________________
|
|
|
|
FD_ZERO macro
|
|
|
|
The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses
|
|
[74]invalid asm clobbers. The following rewrite by Ulrich Drepper
|
|
<drepper@cygnus.com> should fix this for glibc 2.0:
|
|
# define __FD_ZERO(fdsetp) \
|
|
do { \
|
|
int __d0, __d1; \
|
|
__asm__ __volatile__ ("cld; rep; stosl" \
|
|
: "=m" (((__fd_mask *) \
|
|
(fdsetp))[__FDELT (__FD_SETSIZE)]), \
|
|
"=&c" (__d0), "=&D" (__d1) \
|
|
: "a" (0), "1" (sizeof (__fd_set) \
|
|
/ sizeof (__fd_mask)), \
|
|
"2" ((__fd_mask *) (fdsetp)) \
|
|
: "memory"); \
|
|
} while (0)
|
|
_________________________________________________________________
|
|
|
|
Octave 2.0.13 does not compile
|
|
|
|
Apparently Octave 2.0.13 uses some C++ features which have been
|
|
obsoleted and thus fails to build with EGCS 1.1 and later. This
|
|
[75]patch to Octave should fix this.
|
|
|
|
Octave 2.0.13.96, a test release, has been compiled without patches by
|
|
egcs 1.1.2. It is available at
|
|
[76]ftp://ftp.che.wisc.edu/pub/octave/test-releases/.
|
|
_________________________________________________________________
|
|
|
|
Why can't I initialize a static variable with stdin?
|
|
|
|
This has nothing to do with gcc, but people ask us about it a lot.
|
|
Code like this:
|
|
#include <stdio.h>
|
|
|
|
FILE *yyin = stdin;
|
|
|
|
will not compile with GNU libc (Linux libc6), because stdin is not a
|
|
constant. This was done deliberately, in order for there to be no
|
|
limit on the number of open FILE objects. It is surprising for people
|
|
used to traditional Unix C libraries, but it is permitted by the C
|
|
standard.
|
|
|
|
This construct commonly occurs in code generated by old versions of
|
|
lex or yacc. We suggest you try regenerating the parser with a current
|
|
version of flex or bison, respectively. In your own code, the
|
|
appropriate fix is to move the initialization to the beginning of
|
|
main.
|
|
|
|
There is a common misconception that the GCC developers are
|
|
responsible for GNU libc. These are in fact two entirely separate
|
|
projects. The appropriate place to ask questions relating to GNU libc
|
|
is [77]libc-alpha@sourceware.cygnus.com.
|
|
_________________________________________________________________
|
|
|
|
Why can't I use #if here?
|
|
|
|
Let me guess... you wrote code that looks something like this:
|
|
memcpy(dest, src,
|
|
#ifdef PLATFORM1
|
|
12
|
|
#else
|
|
24
|
|
#endif
|
|
);
|
|
|
|
and you got a whole pile of error messages:
|
|
test.c:11: warning: preprocessing directive not recognized within macro arg
|
|
test.c:11: warning: preprocessing directive not recognized within macro arg
|
|
test.c:11: warning: preprocessing directive not recognized within macro arg
|
|
test.c: In function `foo':
|
|
test.c:6: undefined or invalid # directive
|
|
test.c:8: undefined or invalid # directive
|
|
test.c:9: parse error before `24'
|
|
test.c:10: undefined or invalid # directive
|
|
test.c:11: parse error before `#'
|
|
|
|
The problem, simply put, is that GCC's preprocessor does not allow you
|
|
to put #ifdef (or any other directive) inside the arguments of a
|
|
macro. Your C library's string.h happens to define memcpy as a macro -
|
|
this is perfectly legitimate. The code therefore will not compile.
|
|
|
|
We have two good reasons for not allowing directives inside macro
|
|
arguments. First, it is not portable. It is "undefined behavior"
|
|
according to the C standard; that means different compilers will do
|
|
different things with it. Some will give you errors. Some will dump
|
|
core. Some will silently mangle your code - you could get the
|
|
equivalent of
|
|
memcpy(dest, src, 1224);
|
|
|
|
from the above example. A very few might do what you expected it to.
|
|
We therefore feel it is most useful for GCC to reject this construct
|
|
immediately so that it is found and fixed.
|
|
|
|
Second, it is extraordinarily difficult to implement the preprocessor
|
|
such that it does what you would expect for every possible directive
|
|
found inside a macro argument. The best example is perhaps
|
|
#define foo(arg) ... arg ...
|
|
foo(blah
|
|
#undef foo
|
|
blah)
|
|
|
|
which is impossible to implement in portable C without leaking memory.
|
|
Allowing only a subset of directives would be confusing.
|
|
|
|
It is always possible to rewrite code which uses conditionals inside
|
|
macros so that it doesn't. You could write the above example
|
|
#ifdef PLATFORM1
|
|
memcpy(dest, src, 12);
|
|
#else
|
|
memcpy(dest, src, 24);
|
|
#endif
|
|
|
|
This is a bit more typing, but I personally think it's better style in
|
|
addition to being more portable.
|
|
_________________________________________________________________
|
|
|
|
Miscellaneous
|
|
|
|
Virtual memory exhausted error
|
|
|
|
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.
|
|
|
|
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.
|
|
_________________________________________________________________
|
|
|
|
Snapshots, how, when, why
|
|
|
|
We make snapshots of the GCC 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.
|
|
|
|
If you plan on downloading and using snapshots, we highly recommend
|
|
you subscribe to the GCC mailing lists. See [78]mailing lists on the
|
|
main GCC page for instructions on how to subscribe.
|
|
|
|
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.
|
|
_________________________________________________________________
|
|
|
|
Friend Templates
|
|
|
|
In order to make a specialization of a template function a friend of a
|
|
(possibly template) class, you must explicitly state that the friend
|
|
function is a template, by appending angle brackets to its name, and
|
|
this template function must have been declared already. Here's an
|
|
example:
|
|
template <typename T> class foo {
|
|
friend void bar(foo<T>);
|
|
}
|
|
|
|
The above declaration declares a non-template function named bar, so
|
|
it must be explicitly defined for _each_ specialization of foo. A
|
|
template definition of bar won't do, because it is unrelated with the
|
|
non-template declaration above. So you'd have to end up writing:
|
|
void bar(foo<int>) { /* ... */ }
|
|
void bar(foo<void>) { /* ... */ }
|
|
|
|
If you meant bar to be a template function, you should have
|
|
forward-declared it as follows. Note that, since the template function
|
|
declaration refers to the template class, the template class must be
|
|
forward-declared too:
|
|
template <typename T>
|
|
class foo;
|
|
|
|
template <typename T>
|
|
void bar(foo<T>);
|
|
|
|
template <typename T>
|
|
class foo {
|
|
friend void bar<>(foo<T>);
|
|
};
|
|
|
|
template <typename T>
|
|
void bar(foo<T>) { /* ... */ }
|
|
|
|
In this case, the template argument list could be left empty, because
|
|
it can be implicitly deduced from the function arguments, but the
|
|
angle brackets must be present, otherwise the declaration will be
|
|
taken as a non-template function. Furthermore, in some cases, you may
|
|
have to explicitly specify the template arguments, to remove
|
|
ambiguity.
|
|
|
|
An error in the last public comment draft of the ANSI/ISO C++ Standard
|
|
and the fact that previous releases of gcc would accept such friend
|
|
declarations as template declarations has led people to believe that
|
|
the forward declaration was not necessary, but, according to the final
|
|
version of the Standard, it is.
|
|
_________________________________________________________________
|
|
|
|
Where to find libg++
|
|
|
|
Many folks have been asking where to find libg++ for GCC. First we
|
|
should point out that few programs actually need libg++; most only
|
|
need libstdc++/libio which are included in the GCC distribution.
|
|
|
|
If you do need libg++ you can get a libg++ release that works with GCC
|
|
from [79]ftp://egcs.cygnus.com/pub/egcs/infrastructure/. Note that the
|
|
2.8.2 snapshot pre-dates the 2.8.1.2 release.
|
|
_________________________________________________________________
|
|
|
|
autoconf, bison, xgettext, automake, etc
|
|
|
|
If you're using diffs up dated from one snapshot to the next, or if
|
|
you're using the CVS repository, you may need several additional
|
|
programs to build GCC.
|
|
|
|
These include, but are not necessarily limited to autoconf, automake,
|
|
bison, and xgettext.
|
|
|
|
This is necessary because neither diff nor cvs keep timestamps
|
|
correct. This causes problems for generated files as "make" may think
|
|
those generated files are out of date and try to regenerate them.
|
|
|
|
An easy way to work around this problem is to use the gcc_update
|
|
script in the contrib subdirectory of GCC, which handles this
|
|
transparently without requiring installation of any additional tools.
|
|
(Note: Up to and including GCC 2.95 this script was called egcs_update
|
|
.)
|
|
|
|
When building from diffs or CVS or if you modified some sources, you
|
|
may also need to obtain development versions of some GNU tools, as the
|
|
production versions do not necessarily handle all features needed to
|
|
rebuild GCC.
|
|
|
|
Autoconf is available from [80]http://sourceware.cygnus.com/autoconf/;
|
|
have a look at [81]ftp://egcs.cygnus.com/pub/egcs/infrastructure/ for
|
|
the other packages.
|
|
_________________________________________________________________
|
|
|
|
Conflicts when using cvs update
|
|
|
|
It is not uncommon to get CVS conflict messages for some generated
|
|
files when updating your local sources from the CVS repository.
|
|
Typically such conflicts occur with bison or autoconf generated files.
|
|
|
|
As long as you haven't been making modifications to the generated
|
|
files or the generator files, it is safe to delete the offending file,
|
|
then run cvs update again to get a new copy.
|
|
_________________________________________________________________
|
|
|
|
Problems debugging GCC code
|
|
|
|
On some systems GCC will produce dwarf debug records by default;
|
|
however the gdb-4.16 release may not be able to read such debug
|
|
records.
|
|
|
|
You can either use the argument "-gstabs" instead of "-g" or pick up a
|
|
copy of gdb-4.17 to work around the problem.
|
|
_________________________________________________________________
|
|
|
|
Using GCC with GNAT/Ada
|
|
|
|
The GNU Ada front-end is not currently supported by GCC; however, it
|
|
is possible to build the GNAT compiler with a little work.
|
|
|
|
First, retrieve the gnat-3.10p sources. The sources for the Ada front
|
|
end and runtime all live in the "ada" subdirectory. Move that
|
|
subdirectory to egcs/gcc/ada.
|
|
|
|
Second, apply the patch found in egcs/gcc/README.gnat.
|
|
|
|
Finally, rebuild per the GNAT build instructions.
|
|
_________________________________________________________________
|
|
|
|
Using GCC with GNU Pascal
|
|
|
|
The [82]GNU Pascal front-end does work with EGCS 1.1 It does not work
|
|
with EGCS 1.0.x and the main branch of the CVS repository. A tarball
|
|
can be found at
|
|
[83]ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/.
|
|
_________________________________________________________________
|
|
|
|
Using CVS to download snapshots
|
|
|
|
It is possible to checkout specific snapshots with CVS or to check out
|
|
the latest snapshot.
|
|
|
|
We use CVS tags to identify each snapshot we make. Snapshot tags have
|
|
the form "egcs_ss_YYYYMMDD". In addition, the latest official snapshot
|
|
always has the tag "gcc_latest_snapshot".
|
|
_________________________________________________________________
|
|
|
|
Why can't I build a shared library?
|
|
|
|
When building a shared library you may get an error message from the
|
|
linker like `assert pure-text failed:' or `DP relative code in file'.
|
|
|
|
This kind of error occurs when you've failed to provide proper flags
|
|
to gcc when linking the shared library.
|
|
|
|
You can get this error even if all the .o files for the shared library
|
|
were compiled with the proper PIC option. When building a shared
|
|
library, gcc will compile additional code to be included in the
|
|
library. That additional code must also be compiled with the proper
|
|
PIC option.
|
|
|
|
Adding the proper PIC option (-fpic or -fPIC) to the link line which
|
|
creates the shared library will fix this problem on targets that
|
|
support PIC in this manner. For example:
|
|
gcc -c -fPIC myfile.c
|
|
gcc -shared -o libmyfile.so -fPIC myfile.o
|
|
_________________________________________________________________
|
|
|
|
How to work around too long C++ symbol names? (-fsquangle)
|
|
|
|
If the standard assembler of your platform can't cope with the large
|
|
symbol names that the default g++ name mangling mechanism produces,
|
|
your best bet is to use GNU as, from the GNU binutils package.
|
|
|
|
Unfortunately, GNU as does not support all platforms supported by
|
|
egcs, so you may have to use an experimental work-around: the
|
|
-fsquangle option, that enables compression of symbol names.
|
|
|
|
Note that this option is still under development, and subject to
|
|
change. Since it modifies the name mangling mechanism, you'll need to
|
|
build libstdc++ and any other C++ libraries with this option enabled.
|
|
Furthermore, if this option changes its behavior in the future, you'll
|
|
have to rebuild them all again. :-(
|
|
|
|
This option can be enabled by default by initializing
|
|
`flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is not
|
|
initialized by default), then rebuilding egcs and any C++ libraries.
|
|
_________________________________________________________________
|
|
|
|
When building from CVS sources, I see 'gperf: invalid option -- F', even with
|
|
the most current version of gperf.
|
|
|
|
The current version of gperf (v2.7) does not support the -F flag which
|
|
is used when building egcs from CVS sources. You will need to obtain a
|
|
patch for gperf and rebuild the program; this patch is available at
|
|
[84]ftp://egcs.cygnus.com/pub/egcs/infrastructure/
|
|
|
|
Patches for other tools, particularly autoconf, may also be necessary
|
|
if you're building from CVS sources. Please see the [85]FAQ entry
|
|
regarding these tools to determine if anything else is needed.
|
|
|
|
These patched utilities should _only_ be required if you are building
|
|
from CVS sources. For example, gperf is used to generate C code for a
|
|
perfect hash function given an input file. Distributions of egcs
|
|
already contain the generated C code, while the CVS sources will
|
|
provide only the gperf input file. So gperf should only be necessary
|
|
if you are building anything obtained from CVS.
|
|
_________________________________________________________________
|
|
|
|
When building C++, the linker says my constructors, destructors or virtual
|
|
tables are undefined, but I defined them
|
|
|
|
The ISO C++ Standard specifies that all virtual methods of a class
|
|
that are not pure-virtual must be defined, but does not require any
|
|
diagnostic for violations of this rule [class.virtual]/8. Based on
|
|
this assumption, egcs will only emit the implicitly defined
|
|
constructors, the assignment operator, the destructor and the virtual
|
|
table of a class in the translation unit that defines its first such
|
|
non-inline method.
|
|
|
|
Therefore, if you fail to define this particular method, the linker
|
|
may complain about the lack of definitions for apparently unrelated
|
|
symbols. Unfortunately, in order to improve this error message, it
|
|
might be necessary to change the linker, and this can't always be
|
|
done.
|
|
|
|
The solution is to ensure that all virtual methods that are not pure
|
|
are defined. Note that a destructor must be defined even if it is
|
|
declared pure-virtual [class.dtor]/7.
|
|
_________________________________________________________________
|
|
|
|
What is libstdc++-v3 and how can I use it with g++?
|
|
|
|
From the [86]libstdc++-FAQ: "The EGCS Standard C++ Library v3, or
|
|
libstdc++-2.90.x, is an ongoing project to implement the ISO 14882
|
|
Standard C++ library as described in chapters 17 through 27 and annex
|
|
D."
|
|
|
|
At the moment the libstdc++-v3 is no "drop in replacement" for GCC's
|
|
libstdc++. The best way to use it is as follows:
|
|
1. Build and install GCC
|
|
2. Build and install libstdc++-v3
|
|
3. Use compiler flags to use the new libstdc++
|
|
|
|
Please note that the libstdc++-v3 is not yet complete and should only
|
|
be used by experienced programmers.
|
|
|
|
For more information please refer to the [87]libstdc++-v3 homepage
|
|
_________________________________________________________________
|
|
|
|
[88]Return to the GCC home page
|
|
|
|
_Last modified: October 19, 1999_
|
|
|
|
References
|
|
|
|
1. http://www.gnu.org/software/gcc/faq.html
|
|
2. http://www.eskimo.com/~scs/C-faq/top.html
|
|
3. http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/
|
|
4. http://reality.sgi.com/austern_mti/std-c++/faq.html
|
|
5. http://www.fortran.com/fortran/info.html
|
|
6. http://gcc.gnu.org/faq.html#general
|
|
7. http://gcc.gnu.org/faq.html#gcc
|
|
8. http://gcc.gnu.org/faq.html#cygnus
|
|
9. http://gcc.gnu.org/faq.html#open-development
|
|
10. http://gcc.gnu.org/faq.html#bugreport
|
|
11. http://gcc.gnu.org/faq.html#support
|
|
12. http://gcc.gnu.org/faq.html#installation
|
|
13. http://gcc.gnu.org/faq.html#fortran
|
|
14. http://gcc.gnu.org/faq.html#multiple
|
|
15. http://gcc.gnu.org/faq.html#rpath
|
|
16. http://gcc.gnu.org/faq.html#rpath
|
|
17. http://gcc.gnu.org/faq.html#gas
|
|
18. http://gcc.gnu.org/faq.html#environ
|
|
19. http://gcc.gnu.org/faq.html#testsuite
|
|
20. http://gcc.gnu.org/faq.html#testsuite
|
|
21. http://gcc.gnu.org/faq.html#dejagnu
|
|
22. http://gcc.gnu.org/faq.html#testoptions
|
|
23. http://gcc.gnu.org/faq.html#multipletests
|
|
24. http://gcc.gnu.org/faq.html#platform
|
|
25. http://gcc.gnu.org/faq.html#x86eh
|
|
26. http://gcc.gnu.org/faq.html#asmclobber
|
|
27. http://gcc.gnu.org/faq.html#linuxkernel
|
|
28. http://gcc.gnu.org/faq.html#X11R6
|
|
29. http://gcc.gnu.org/faq.html#cross
|
|
30. http://gcc.gnu.org/faq.html#bugs
|
|
31. http://gcc.gnu.org/faq.html#fdzero
|
|
32. http://gcc.gnu.org/faq.html#octave
|
|
33. http://gcc.gnu.org/faq.html#stdin
|
|
34. http://gcc.gnu.org/faq.html#macarg
|
|
35. http://gcc.gnu.org/faq.html#misc
|
|
36. http://gcc.gnu.org/faq.html#memexhausted
|
|
37. http://gcc.gnu.org/faq.html#snapshot
|
|
38. http://gcc.gnu.org/faq.html#friend
|
|
39. http://gcc.gnu.org/faq.html#libg++
|
|
40. http://gcc.gnu.org/faq.html#generated_files
|
|
41. http://gcc.gnu.org/faq.html#gdb
|
|
42. http://gcc.gnu.org/faq.html#conflicts
|
|
43. http://gcc.gnu.org/faq.html#gnat
|
|
44. http://gcc.gnu.org/faq.html#gpc
|
|
45. http://gcc.gnu.org/faq.html#cvssnapshots
|
|
46. http://gcc.gnu.org/faq.html#picflag-needed
|
|
47. http://gcc.gnu.org/spam.html
|
|
48. http://gcc.gnu.org/faq.html#squangle
|
|
49. http://gcc.gnu.org/faq.html#gperf
|
|
50. http://gcc.gnu.org/faq.html#vtables
|
|
51. http://gcc.gnu.org/faq.html#libstdc++
|
|
52. http://gcc.gnu.org/steering.html
|
|
53. http://gcc.gnu.org/steering.html
|
|
54. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar
|
|
55. http://locke.ccil.org/~esr/writings/cathedral.html
|
|
56. http://gcc.gnu.org/onlinedocs/
|
|
57. http://egcs.cygnus.com/cgi-bin/cvsweb.cgi/~checkout~/egcs/gcc/BUGS?content-type=text/plain&only_with_tag=HEAD
|
|
58. http://gcc.gnu.org/bugs.html
|
|
59. mailto:gcc-bugs@gcc.gnu.org
|
|
60. mailto:bug-gcc@gnu.org
|
|
61. http://gcc.gnu.org/faq.html#bugreport
|
|
62. http://gcc.gnu.org/faq.html#gas
|
|
63. http://gcc.gnu.org/install/specific.html
|
|
64. ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-19981026.tar.gz
|
|
65. http://gcc.gnu.org/install/specific.html
|
|
66. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/
|
|
67. http://gcc.gnu.org/faq.html#bugreport
|
|
68. http://gcc.gnu.org/faq.html#linuxkernel
|
|
69. http://www.suse.de/~florian/kernel+egcs.html
|
|
70. http://gcc.gnu.org/faq.html#asmclobber
|
|
71. http://www.objsw.com/CrossGCC/
|
|
72. http://gcc.gnu.org/bugs.html
|
|
73. http://gcc.gnu.org/faq.html#bugreport
|
|
74. http://gcc.gnu.org/faq.html#asmclobber
|
|
75. http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/270
|
|
76. ftp://ftp.che.wisc.edu/pub/octave/test-releases/
|
|
77. mailto:libc-alpha@sourceware.cygnus.com
|
|
78. http://gcc.gnu.org/index.html#mailinglists
|
|
79. ftp://egcs.cygnus.com/pub/egcs/infrastructure/
|
|
80. http://sourceware.cygnus.com/autoconf/
|
|
81. ftp://egcs.cygnus.com/pub/egcs/infrastructure/
|
|
82. http://home.pages.de/~GNU-Pascal/
|
|
83. ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/
|
|
84. ftp://egcs.cygnus.com/pub/egcs/infrastructure
|
|
85. http://gcc.gnu.org/faq.html#generated_files
|
|
86. http://sourceware.cygnus.com/libstdc++/faq/
|
|
87. http://sourceware.cygnus.com/libstdc++/
|
|
88. http://gcc.gnu.org/index.html
|