g++faq.texi

来自「GCC编译器源代码」· TEXI 代码 · 共 1,691 行 · 第 1/5 页

@node repository, repo bugs, shared libraries, installation
@section How do I use the new repository code?

@cindex repo patch
Because there is some disagreement about the details of the template
repository mechanism, you'll need to obtain a patch from Cygnus Support
to enable the 2.7.2 repository code.  You can obtain the patch by
anonymous FTP: @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz}.

There are patches for 2.7.0 and 2.7.1 in the same directory, though
if you're going to rebuild the compiler you should use the latest one.

@cindex repo patch for BSD
If you're running NetBSD or BSDI, the Cygnus repo patch is not quite
correct.  Tim Liddelow has made an alternate version available at
@file{ftp://ftp.cst.com.au/pub/gcc-2.7.2-repo-bsd.gz}.

After you've applied the patch, the @code{-frepo} flag will enable the
repository mechanism.  The flag works much like the existing
@code{-fno-implicit-templates} flag, except that auxiliary files, with
an @file{.rpo} extension, are built that specify what template
expansions are needed.  At link time, the (patched) collect program
detects missing templates and recompiles some of the object files
so that the required templates are expanded.

Note that the mechanism differs from that of cfront in that template
definitions still must be visible at the point where they are to be
expanded.  No assumption is made that @file{foo.C} contains template
definitions corresponding to template declarations in @file{foo.h}.

@cindex closure with repo
@cindex template closure
Jason Merrill writes: ``To perform closure on a set of objects, just try
to link them together.  It will fail, but as a side effect all needed
instances will be generated in the objects.''

@node repo bugs, Use GNU C library?, repository, installation
@section Known bugs and problems with the repo patch

``The @code{-frepo} won't expand templated friend functions!''

This is a known bug; currently you'll have to explicitly instantiate
friend functions when using @code{-frepo} due to this bug (in 2.7.0
through 2.7.2 at least).

With earlier versions of the repo patch, there was a bug that happens
when you have given a quoted command line switch, something like

@example
-D'MESSAGE="hello there"'
@end example

The repo code tries to recompile files using the same flags you
originally specified, but doesn't quote arguments that need quoting,
resulting in failures in some cases.  This is no longer a problem
with the 2.7.2 patch.

@node Use GNU C library?, Global constructor problems, repo bugs, installation
@section Should I use the GNU C library?

@cindex GNU C library
@cindex libg++
At this point in time, no (unless you are running Linux or the GNU Hurd
system).  The GNU C library is still very young, and
libg++ still conflicts with it in some places.  Use your native C library
unless you know a lot about the gory details of libg++ and gnu-libc.  This
will probably change in the future.

@node Global constructor problems, Strange assembler errors, Use GNU C library?, installation
@section Global constructors aren't being called

@cindex global constructors
``I've installed gcc and it almost works, but constructors and
destructors for global objects and objects at file scope aren't being
called.  What did I do wrong?''

@cindex collect program
It appears that you are running on a platform that requires you to
install either "collect2" or the GNU linker, and you have done neither.
For more information, see the section discussing the GNU linker
(@pxref{use GNU linker?}).

@cindex constructor problems on Solaris
@cindex Solaris, constructor problems
On Solaris 2.x, you shouldn't need a collect program and GNU ld doesn't run.
If your global constructors aren't being called, you may need to install
a patch, available from Sun, to fix your linker.  The number of the
``jumbo patch'' that applies is 101409-03.  Thanks to Russell Street
(r.street@@auckland.ac.nz) for this info.

@cindex IRIX, installing collect
It appears that on IRIX, the collect2 program is not being installed
by default during the installation process, though it is required;
you can install it manually by executing

@example
make install-collect2
@end example

from the gcc source directory after installing the compiler.  (I'm
not certain for which versions of gcc this problem occurs, and whether
it is still present).

@node Strange assembler errors, Other problems building libg++, Global constructor problems, installation
@section Strange assembler errors when linking C++ programs

``I've installed gcc and it seemed to go OK, but when I attempt to link
any C++ program, I'm getting strange errors from the assembler!  How
can that be?''

The messages in question might look something like

@example
as: "/usr/tmp/cca14605.s", line 8: error: statement syntax
as: "/usr/tmp/cca14605.s", line 14: error: statement syntax
@end example

(on a Sun, different on other platforms).  The important thing is that
the errors come out at the link step, @emph{not} when a C++ file is
being compiled.

@cindex nm program
@cindex GNU nm program
Here's what's going on: the collect2 program uses the Unix ``nm''
program to obtain a list of symbols for the global constructors and
destructors, and it builds a little assembly language module that
will permit them all to be called.  If you're seeing this symptom,
you have an old version of GNU nm somewhere on your path.  This old
version prints out symbol names in a format that the collect2 program
does not expect, so bad assembly code is generated.

The solution is either to remove the old version of GNU nm from your
path (and that of everyone else who uses g++), or to install a newer
version (it is part of the GNU "binutils" package).  Recent versions
of GNU nm do not have this problem.

@node Other problems building libg++, More size_t problems, Strange assembler errors, installation
@section Other problems building libg++
@cindex libg++ on Ultrix
@cindex libg++ on SunOS

``I am having trouble building libg++.  Help!''

On some platforms (for example, Ultrix), you may see errors complaining
about being unable to open dummy.o.  On other platforms (for example,
SunOS), you may see problems having to do with the type of size_t.
The fix for these problems is to make libg++ by saying "make CC=gcc".
According to Per Bothner, it should no longer be necessary to specify
"CC=gcc" for libg++-2.3.1 or later.

``I built and installed libg++, but g++ can't find it.  Help!''

The string given to @file{configure} that identifies your system must
be the same when you install libg++ as it was when you installed gcc.
Also, if you used the @code{--prefix} option to install gcc somewhere
other than @file{/usr/local}, you must use the same value for
@code{--prefix} when installing libg++, or else g++ will not be able
to find libg++.

@cindex patch for libg++-2.6.2

The toplevel Makefile in the libg++ 2.6.2 distribution is broken, which
along with a bug in g++ 2.6.3 causes problems linking programs that use the
libstdc++ complex classes.  A patch for this is available from
@file{ftp://ftp.cygnus.com//pub/g++/libg++-2.6.2-fix.gz}.

@node More size_t problems, Rebuild libg++?, Other problems building libg++, installation
@section But I'm @emph{still} having problems with @code{size_t}!

@cindex Type of size_t
``I did all that, and I'm @emph{still} having problems with disagreeing
definitions of size_t, SIZE_TYPE, and the type of functions like
@code{strlen}.''

@cindex _G_config.h
The problem may be that you have an old version of @file{_G_config.h}
lying around.  As of libg++ version 2.4, @file{_G_config.h}, since it is
platform-specific, is inserted into a different directory; most include
files are in @file{$prefix/lib/g++-include}, but this file now lives in
@file{$prefix/$arch/include}.  If, after upgrading your libg++, you find that
there is an old copy of @file{_G_config.h} left around, remove it,
otherwise g++ will find the old one first.

@node Rebuild libg++?, co-existing versions, More size_t problems, installation
@section Do I need to rebuild libg++ to go with my new g++?

``After I upgraded g++ to the latest version, I'm seeing undefined
symbols.''

or

``If I upgrade to a new version of g++, do I need to reinstall libg++?''

@cindex Incompatibilities between g++ versions

As a rule, the first two digits of your g++ and libg++ should be the
same.  Normally when you do an upgrade in the ``minor version number''
(2.5.7 to 2.5.8, say) there isn't a need to rebuild libg++, but there
have been a couple of exceptions in the past.

@node co-existing versions, Installing on Linux, Rebuild libg++?, installation
@section I want several versions of g++ and libg++ to co-exist.

I recommend against using the @code{-V} flag to make multiple versions
of gcc/g++ co-exist, unless they are different minor releases that can use
the same compiled version of libg++.  The reason is that all these
versions will try to use the same libg++ version, which usually will
not work.

Instead, use the @code{--prefix} flag when configuring gcc.  Use a
different value of @code{--prefix} for each gcc version.  Use the
same value of @code{--prefix} when configuring libg++.  You can then
have any number of co-existing gcc/libg++ pairs.  Symbolic links can
be used so that users don't need to put all these different directories
on their paths.

One possible system to use is to set @code{--prefix} to
@file{/usr/local/gcc-2.x.y} for version 2.x.y of gcc, and to link
whichever version of gcc you wish to be the default into
@file{/usr/local/bin/gcc} and @file{/usr/local/bin/g++}.

@node Installing on Linux, Linux Slackware 3.0, co-existing versions, installation
@section Trouble installing g++ and libg++ on Linux

``I've downloaded the latest g++ and libg++ and I'm trying to install
them on Linux, and I'm having lots of problems.''

@cindex Linux
FSF releases of libg++ won't install on Linux unchanged, since Linux
uses are part of the libio library from libg++ for its standard C
library, only this is changed in a way that it clashes with libg++.
This means that you'll need a patched version of libg++ for it to
work.

If you want to upgrade to a new gcc/libg++ combination, the easiest
thing to do is to grab the prebuilt versions of gcc and libg++ for Linux
from @file{ftp://tsx-11.mit.edu/pub/linux/packages/GCC}.  Follow the
directions carefully.  If you want to build from source, you'll need
a patch for libg++; the Linux developers have named the patched libg++
version libg++-2.7.1.3 and there is a patch file in the above-named
directory.

See @file{http://sunsite.unc.edu/LDP/HOWTO/GCC-HOWTO.html},
the Linux GCC HOWTO, for more on gcc/g++ and Linux.

Linux is in the process of switching over to the GNU C library, version
2, which will become Linux libc version 6.  Once this process is
complete, there's a good chance that the installation process on Linux
will be smoother, but only experts should try making this new library
work at this point.

@node Linux Slackware 3.0,  , Installing on Linux, installation
@section Problems with g++ on Linux Slackware 3.0

@cindex Slackware
@cindex Linux Slackware
``When I try to compile the traditional Hello, world program on Linux,
the compiler can't find @file{iostream.h}.  What's the deal?''

You probably have the Slackware 3.0 release.  There's an error in the
setup.  It's easy to fix, though; log in as root, and make a symbolic
link:

@example
ln -s /usr/lib/g++-include /usr/include/g++
@end example

@node evolution, User Problems, installation, Top
@chapter The Evolution of g++

This chapter discusses the evolution of g++ and describes what can be expected
in the future.

@menu
* version 2.7.x::               What's changed in 2.7.x from earlier versions
* libstdc++::                   The GNU C++ standard library
* new work::                    What's been done since 2.7.x
* egcs::                        The Experimental GNU Compiler System
* When?::                       When can I get all this new stuff?
@end menu

@node version 2.7.x, libstdc++, evolution, evolution
@section What's new in version 2.7.x of gcc/g++

The current version of gcc/g++ is 2.7.2.2, released February 10, 1997.
The only change between 2.7.2.1 and 2.7.2.2 is that support was added
for using the GNU C library, version 2, on Linux; users not interested
in that functionality have no reason to upgrade.
The previous version of gcc/g++ is 2.7.2.1, released August 14, 1996.
The current version of libg++ is 2.7.2, released July 4, 1996.

Note that gcc 2.7.2.1 just consists of several small patches to
gcc-2.7.2.  The release is mainly
intended to fix platform-specific bugs and does not affect the C++
``front end'' of the compiler (the part that parses your C++ code).

The 2.7.x releases represent a great deal of work on the part of the g++
maintainers to fix outstanding bugs and move the compiler closer to the
current ANSI/ISO standards committee's working paper, including
supporting many of the new features that have been added to the
language.  I recommend that everyone read the NEWS file contained in the
distribution (and that system administrators make the file available to
their users).  I've borrowed liberally from this file here.

@cindex C++ working paper
If any features seem unfamiliar, you will probably want to
look at the recently-released public review copy of the C++ Working
Paper.  A new draft, dated 2 December 1996, has been released for
public comment.  You can find it on the web at
@file{http://www.cygnus.com/misc/wp/} or
@file{http://www.maths.warwick.ac.uk/c++/pub/wp/html/cd2/}.
See
@file{http://www.setech.com/x3.html}
or
@file{http://www.maths.warwick.ac.uk/c++/pub/} to download the
document in PostScript, PDF (Adobe Acrobat), HTML, or ASCII
form.

Here are the main points:

@itemize @bullet
@item
@cindex for scope
As described above, the scope of variables declared in the
initialization part of a for statement has been changed; such variables
are now visible only in the loop body.  Use @code{-fno-for-scope} to get
the old behavior.  You'll need this flag to build groff version 1.09,
Ptolemy, and many other free software packages.

@item
@cindex vtable duplication
Code that does not use #pragma interface/implementation will most
likely shrink dramatically, as g++ now only emits the vtable for a
class in the translation unit where its first non-inline, non-abstract
virtual function is defined.

@item
@cindex automatic template instantiation
Support for automatic template instantiation has @emph{not} been enabled