General information

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 decreasing 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 its benefits and
disadvantages.

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.

Report the problem to the GCC bug tracking system
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 this method that you would see
from a commercial support organization since the people who read
GCC bug reports, if they choose to help you, will be volunteering their
time.

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.

The host/target specific installation notes for GCC include information
about known problems with installing or using GCC on particular platforms.
These are included in the sources for a release in INSTALL/specific.html,
and the latest version
is always available at the GCC web site.
Reports of successful builds
for several versions of GCC are also available at the web site.

Installation

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, GCC can not find GNU
as/GNU ld explains how to deal with this.

Another option that may be easier is to use the
--program-prefix= or --program-suffix=
options to configure. So if you're installing GCC 2.95.2 and don't
want to disturb the current version of GCC in
/usr/local/bin/, you could do

configure --program-suffix=-2.95.2 <other configure options>

This should result in GCC being installed as
/usr/local/bin/gcc-2.95.2 instead of
/usr/local/bin/gcc.

This problem manifests itself by programs not finding shared
libraries they depend on when the programs are started. (This
often shows around libstdc++.)

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, your programs become dependent on directories which
may be NFS mounted, and programs — even those which do not
require these directories — may hang unnecessarily when an
NFS server goes down.
(SunOS effectively always passed a -R option for every
-L option; this was a bad idea, and it was removed for
Solaris.)

However, if you feel you really need such an option to be passed
automatically to the linker, you may add it to a GCC specs file.
This file can be created using gcc -dumpspecs and passed
to GCC using the -specs= option. You may add linker
flags such as -R or -rpath, depending on
platform and linker, to the *link or *lib
specs.

Alternately the syntax -Wl,option can be used to ask
GCC to transfer the flag option to the linker.

Another alternative 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).

GCC searches the PATH for an assembler and a linker, 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 assembler and linker 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 linker), which
are required by 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.

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.

The Java front end requires iconv. If the compiler
used to bootstrap GCC finds libiconv (because the GNU
version of libiconv has been installed in the same prefix
as the bootstrap compiler), but the newly built GCC does not find the
library (because it will be installed with a different prefix), then a
link-time error will occur when building jc1. This
problem does not show up so often on platforms that have
libiconv in a default location (like
/usr/lib) because then both compilers can find a library
named libiconv, even though it is a different
library.

Using --disable-nls at configure-time does not
prevent this problem because jc1 uses
iconv even in that case. Solutions include temporarily
removing the GNU libiconv, copying it to a default
location such as /usr/lib/, and using
--enable-languages at configure-time to disable Java.

Miscellaneous

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:

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.

The new C++ ABI in the GCC 3.0 series uses address comparisons,
rather than string compares, to determine type equality. This leads
to better performance. Like other objects that have to be present in the
final executable, these std::type_info objects have what
is called vague linkage because they are not tightly bound to any one
particular translation unit (object file). The compiler has to emit
them in any translation unit that requires their presence, and then
rely on the linking and loading process to make sure that only one of
them is active in the final executable. With static linking all of
these symbols are resolved at link time, but with dynamic linking,
further resolution occurs at load time. You have to ensure that
objects within a shared library are resolved against objects in the
executable and other shared libraries.

For a program which is linked against a shared library, no additional
precautions are needed.

You cannot create a shared library with the "-Bsymbolic"
option, as that prevents the resolution described above.

If you use dlopen to explicitly load code from a shared
library, you must do several things. First, export global symbols from
the executable by linking it with the "-E" flag (you will
have to specify this as "-Wl,-E" if you are invoking
the linker in the usual manner from the compiler driver, g++).
You must also make the external symbols in the loaded library
available for subsequent libraries by providing the RTLD_GLOBAL
flag to dlopen. The symbol resolution can be immediate or
lazy.

Template instantiations are another, user visible, case of objects
with vague linkage, which needs similar resolution. If you do not take
the above precautions, you may discover that a template instantiation
with the same argument list, but instantiated in multiple translation
units, has several addresses, depending in which translation unit the
address is taken. (This is not an exhaustive list of the kind
of objects which have vague linkage and are expected to be resolved
during linking & loading.)

If you are worried about different objects with the same name
colliding during the linking or loading process, then you should use
namespaces to disambiguate them. Giving distinct objects with global
linkage the same name is a violation of the One Definition Rule (ODR)
[basic.def.odr].

For more details about the way that GCC implements these and other
C++ features, please read the C++ ABI specification.
Note the std::type_info objects which must be
resolved all begin with "_ZTS". Refer to ld's
documentation for a description of the "-E" &
"-Bsymbolic" flags.

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:

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, GCC 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.

For questions related to the use of GCC,
please consult these web pages and the
GCC manuals. If that fails,
the gcc-help@gcc.gnu.org
mailing list might help.
Comments on these web pages and the development of GCC are welcome on our
developer list at gcc@gcc.gnu.org.
All of our lists
have public archives.

Copyright (C)
Free Software Foundation, Inc.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.