654 lines
31 KiB
Plaintext
654 lines
31 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.std.c++ FAQ, and the [4]Fortran
|
|
Information page.
|
|
|
|
Other GCC-related FAQs: [5]libstdc++-v3, and [6]GCJ.
|
|
_________________________________________________________________
|
|
|
|
Questions
|
|
|
|
1. [7]General information
|
|
1. [8]What is the relationship between GCC and EGCS?
|
|
2. [9]What is the relationship between GCC and Cygnus / Red Hat?
|
|
3. [10]What is an open development model?
|
|
4. [11]How do I report a bug?
|
|
5. [12]How do I get a bug fixed or a feature added?
|
|
6. [13]Does GCC work on my platform?
|
|
2. [14]Installation
|
|
1. [15]How to install multiple versions of GCC
|
|
2. [16]Dynamic linker is unable to find GCC libraries
|
|
3. [17]libstdc++/libio tests fail badly with --enable-shared
|
|
4. [18]GCC can not find GNU as/GNU ld
|
|
5. [19]cpp: Usage:... Error
|
|
6. [20]Optimizing the compiler itself
|
|
3. [21]Testsuite problems
|
|
1. [22]Unable to run the testsuite
|
|
2. [23]How do I pass flags like -fnew-abi to the testsuite?
|
|
3. [24]How can I run the test suite with multiple options?
|
|
4. [25]Older versions of GCC
|
|
1. [26]Is there a stringstream / sstream for GCC 2.95.2?
|
|
5. [27]Miscellaneous
|
|
1. [28]Virtual memory exhausted
|
|
2. [29]Friend Templates
|
|
3. [30]dynamic_cast, throw, typeid don't work with shared
|
|
libraries
|
|
4. [31]Why do I need autoconf, bison, xgettext, automake, etc?
|
|
5. [32]Why can't I build a shared library?
|
|
6. [33]How to work around too long C++ symbol names?
|
|
(-fsquangle)
|
|
7. [34]When building C++, the linker says my constructors,
|
|
destructors or virtual tables are undefined, but I defined
|
|
them
|
|
8. [35]Will GCC someday include an incremental linker?
|
|
_________________________________________________________________
|
|
|
|
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. The net result was a single project which
|
|
carries forward GCC development under the ultimate control of the
|
|
[36]GCC Steering Committee.
|
|
_________________________________________________________________
|
|
|
|
What is the relationship between GCC and Cygnus / Red Hat?
|
|
|
|
It is a common mis-conception that Red Hat controls GCC either
|
|
directly or indirectly.
|
|
|
|
While Red Hat does donate hardware, network connections, code and
|
|
developer time to GCC development, Red Hat does not control GCC.
|
|
|
|
Overall control of GCC is in the hands of the [37]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, Red Hat contributes to the GCC project, but does not
|
|
exert a controlling influence over GCC.
|
|
_________________________________________________________________
|
|
|
|
What is an open development model?
|
|
|
|
We are using a bazaar style [38][1] approach to GCC development: we
|
|
make snapshots publicly available to anyone who wants to try them; we
|
|
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 are adding new features and optimizations at a rate that
|
|
has not been done since the creation of gcc2; these additions
|
|
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 ``[39]The Cathedral and the Bazaar''. The paper is a useful
|
|
starting point for discussions.
|
|
_________________________________________________________________
|
|
|
|
How do I report a bug?
|
|
|
|
There are complete instructions [40]here.
|
|
_________________________________________________________________
|
|
|
|
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 its 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.
|
|
* [41]Report the problem to the GCC GNATS 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. This
|
|
alternative will work best if you follow the directions on
|
|
[42]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.
|
|
_________________________________________________________________
|
|
|
|
Does GCC work on my platform?
|
|
|
|
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 [43]latest version is always
|
|
available at the GCC web site. Reports of [44]successful builds for
|
|
several versions of GCC are also available at the web site.
|
|
_________________________________________________________________
|
|
|
|
Installation
|
|
|
|
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, [45]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.
|
|
_________________________________________________________________
|
|
|
|
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 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).
|
|
|
|
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 [46]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.
|
|
_________________________________________________________________
|
|
|
|
Optimizing the compiler itself
|
|
|
|
If you want to test a particular optimization option, it's useful to
|
|
try bootstrapping the compiler with that option turned on. For
|
|
example, to test the -fssa option, you could bootstrap like this:
|
|
make BOOT_CFLAGS="-O2 -fssa" bootstrap
|
|
_________________________________________________________________
|
|
|
|
Testsuite problems
|
|
|
|
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 from
|
|
[47]http://www.gnu.org/software/dejagnu/dejagnu.html.
|
|
_________________________________________________________________
|
|
|
|
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.
|
|
_________________________________________________________________
|
|
|
|
Older versions of GCC and EGCS
|
|
|
|
Is there a stringstream / sstream for GCC 2.95.2?
|
|
|
|
Yes, it's at:
|
|
[48]http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream.
|
|
_________________________________________________________________
|
|
|
|
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.
|
|
_________________________________________________________________
|
|
|
|
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.
|
|
_________________________________________________________________
|
|
|
|
dynamic_cast, throw, typeid don't work with shared libraries
|
|
|
|
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::typeinfo_t 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 need taking.
|
|
* 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 [49]ABI specification. Note the
|
|
std::typeinfo_t objects which must be resolved all begin with "_ZTS".
|
|
Refer to ld's documentation for a description of the "-E" &
|
|
"-Bsymbolic" flags.
|
|
_________________________________________________________________
|
|
|
|
Why do I need 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.
|
|
|
|
In general, the current versions of these tools from
|
|
[50]ftp://ftp.gnu.org/gnu/ will work. At present, Autoconf 2.50 is not
|
|
supported, and you will need to use Autoconf 2.13; work is in progress
|
|
to fix this problem. Also look at
|
|
[51]ftp://gcc.gnu.org/pub/gcc/infrastructure/ for any special versions
|
|
of packages.
|
|
_________________________________________________________________
|
|
|
|
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)
|
|
|
|
This question does not apply to GCC 3.0 or later versions, which have
|
|
a new C++ ABI with much shorter mangled names.
|
|
|
|
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 GCC,
|
|
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 GCC and any C++ libraries.
|
|
_________________________________________________________________
|
|
|
|
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, 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.
|
|
_________________________________________________________________
|
|
|
|
Will GCC someday include an incremental linker?
|
|
|
|
Incremental linking is part of the linker, not the compiler. As such,
|
|
GCC doesn't have anything to do with incremental linking. Depending on
|
|
what platform you use, it may be possible to tell GCC to use the
|
|
platform's native linker (e.g., Solaris' ild(1)).
|
|
|
|
References
|
|
|
|
1. http://www.gnu.org/software/gcc/faq.html
|
|
2. http://www.eskimo.com/~scs/C-faq/top.html
|
|
3. http://www.research.att.com/~austern/csc/faq.html
|
|
4. http://www.fortran.com/fortran/info.html
|
|
5. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html
|
|
6. http://gcc.gnu.org/java/faq.html
|
|
7. http://gcc.gnu.org/faq.html#general
|
|
8. http://gcc.gnu.org/faq.html#gcc
|
|
9. http://gcc.gnu.org/faq.html#cygnus
|
|
10. http://gcc.gnu.org/faq.html#open-development
|
|
11. http://gcc.gnu.org/faq.html#bugreport
|
|
12. http://gcc.gnu.org/faq.html#support
|
|
13. http://gcc.gnu.org/faq.html#platforms
|
|
14. http://gcc.gnu.org/faq.html#installation
|
|
15. http://gcc.gnu.org/faq.html#multiple
|
|
16. http://gcc.gnu.org/faq.html#rpath
|
|
17. http://gcc.gnu.org/faq.html#rpath
|
|
18. http://gcc.gnu.org/faq.html#gas
|
|
19. http://gcc.gnu.org/faq.html#environ
|
|
20. http://gcc.gnu.org/faq.html#optimizing
|
|
21. http://gcc.gnu.org/faq.html#testsuite
|
|
22. http://gcc.gnu.org/faq.html#dejagnu
|
|
23. http://gcc.gnu.org/faq.html#testoptions
|
|
24. http://gcc.gnu.org/faq.html#multipletests
|
|
25. http://gcc.gnu.org/faq.html#old
|
|
26. http://gcc.gnu.org/faq.html#2.95sstream
|
|
27. http://gcc.gnu.org/faq.html#misc
|
|
28. http://gcc.gnu.org/faq.html#memexhausted
|
|
29. http://gcc.gnu.org/faq.html#friend
|
|
30. http://gcc.gnu.org/faq.html#dso
|
|
31. http://gcc.gnu.org/faq.html#generated_files
|
|
32. http://gcc.gnu.org/faq.html#picflag-needed
|
|
33. http://gcc.gnu.org/faq.html#squangle
|
|
34. http://gcc.gnu.org/faq.html#vtables
|
|
35. http://gcc.gnu.org/faq.html#incremental
|
|
36. http://gcc.gnu.org/steering.html
|
|
37. http://gcc.gnu.org/steering.html
|
|
38. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar
|
|
39. http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
|
|
40. http://gcc.gnu.org/bugs.html
|
|
41. http://gcc.gnu.org/bugs.html
|
|
42. http://gcc.gnu.org/bugs.html
|
|
43. http://gcc.gnu.org/install/specific.html
|
|
44. http://gcc.gnu.org/buildstat.html
|
|
45. http://gcc.gnu.org/faq.html#gas
|
|
46. http://gcc.gnu.org/install/specific.html
|
|
47. http://www.gnu.org/software/dejagnu/dejagnu.html
|
|
48. http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream
|
|
49. http://www.codesourcery.com/cxx-abi/
|
|
50. ftp://ftp.gnu.org/gnu/
|
|
51. ftp://gcc.gnu.org/pub/gcc/infrastructure/
|