g++faq.texi

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

@cindex OpenVMS/Alpha
Klaus Kaempf (kkaempf@@progis.de)
has done a port to OpenVMS for the Alpha; this is not yet a
part of the official gcc/g++.
The port includes g++ and all libraries from the libg++ distribution.  See
@file{http://www.progis.de} for more details.

@cindex MS-DOS support
@cindex Delorie's gcc/g++
@cindex DJGPP
@cindex EMX
There are two different versions of gcc/g++ for MS-DOS: EMX and DJGPP.
EMX also works for OS/2 and is described later.
DJGPP is DJ Delorie's port.  It can be found on many FTP archive
sites; try
@file{ftp://ftp.coast.net/SimTel/vendors/djgpp/}
or, for a complete list, see
@file{http://www.delorie.com/djgpp/getting.html}.


The latest version of DJGPP is 2.00.  See
@file{http://www.delorie.com/djgpp/v2/} for information on this version.

FSF sells floppies with DJGPP on them; see above for ordering software
from the FSF.

DJGPP has its own newsgroup: @file{comp.os.msdos.djgpp}.

@cindex Amiga support
Development and porting efforts for GNU tools, including gcc/g++, for
the Amiga are maintained by an initiative named ADE (Amiga Developers
Environment.  More information about ADE is available at
@file{http://www.ninemoons.com/}.

For more information on Amiga ports of gcc/g++, retrieve the file
@file{ftp://prep.ai.mit.edu/pub/gnu/MicrosPorts/Amiga}.

@cindex Atari ST support
A port of gcc to the Atari ST can be found at @*
@file{ftp://atari.archive.umich.edu/atari/Gnustuff/Tos}
along with many
other GNU programs.  This version is usually the same as the latest FSF
release.  See the ``Software FAQ'' for the Usenet group
@file{comp.sys.atari.st} for more information.

@cindex EMX port 
@cindex OS/2 support

EMX is a port of gcc to OS/2; it can also be used on MS-DOS.  In addition to
the compiler port, the EMX port's C library attempts to provide a
Unix-like environment.  For more information ask around on
@file{comp.os.os2.programmer.porting}.  Version 0.9c, based on gcc-2.7.2.1,
was released in
November 1996.  It is available by FTP and the WWW from, among other
places

@example
@file{http://www.os2ss.com/unix/emx09c/}
@file{ftp://ftp.cdrom.com/pub/os2/emx09c/} (US)
@file{ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/} (Germany)
@end example

Eberhard Mattes did the EMX port.  His address is
mattes@@azu.informatik.uni-stuttgart.de.
Read the FAQ file included with the distribution before harassing the author.

@cindex Apple support
@cindex Macintosh support

I'm looking for more information on gcc/g++ support on the Apple
Macintosh.  Until recently, this FAQ did not provide such information,
but FSF is no longer boycotting Apple as the League for Programming
Freedom boycott has been dropped.

Versions 1.37.1 and 2.3.3 of gcc were ported by Stan Shebs and are available
at @*
@file{ftp://ftp.cygnus.com/pub/mac}

They are both interfaced to MPW.
Stan is working on a version using the current (post-2.7) sources, contact
him directly (shebs@@cygnus.com) for more information.

@node 1.x vs 2.x versions,  , g++ for other platforms, basics
@section But I can only find g++-1.42!

``I keep hearing people talking about g++ 2.7.2 (or some other number
starting with 2), but the latest version I can find is g++ 1.42.
Where is it?''

@cindex Objective-C
@cindex g++, version number
As of gcc 2.0, C, C++, and Objective-C as well are all combined into a
single distribution called gcc.  If you get gcc you already have g++.  The
standard installation procedure for any gcc version 2 compiler will
install the C++ compiler as well.

One could argue that we shouldn't even refer to "g++-2.x.y" but it's a
convention.  It means ``the C++ compiler included with gcc-2.x.y.''

@node installation, evolution, basics, Top
@chapter Installation Issues and Problems

@menu
* gcc-2 + g++-1::               
* what else do I need?::        
* use GNU linker?::             
* Use GNU assembler?::          
* shared libraries::            
* repository::                  
* repo bugs::                   
* Use GNU C library?::          
* Global constructor problems::  
* Strange assembler errors::    
* Other problems building libg++::  
* More size_t problems::        
* Rebuild libg++?::             
* co-existing versions::        
* Installing on Linux::         
* Linux Slackware 3.0::         
@end menu

@node gcc-2 + g++-1, what else do I need?, installation, installation
@section I can't build g++ 1.x.y with gcc-2.x.y!

``I obtained gcc-2.x.y and g++ 1.x.y and I'm trying to build it, but
I'm having major problems.  What's going on?''

@cindex g++, building 
If you wish to build g++-1.42, you must obtain gcc-1.42 first.  The
installation instructions for g++ version 1 leave a lot to be desired,
unfortunately, and I would recommend that, unless you have a special
reason for needing the 1.x compiler, that C++ users use the latest
g++-2.x version, as it
is the version that is being actively maintained.

@cindex g++, template support
@cindex Templates
@cindex ANSI draft standard
There is no template support in g++-1.x, and it is generally much further
away from the ANSI draft standard than g++-2.x is.

@node what else do I need?, use GNU linker?, gcc-2 + g++-1, installation
@section OK, I've obtained gcc; what else do I need?

@cindex libg++
First off, you'll want libg++ as you can do almost nothing without it
(unless you replace it with some other class library).

@cindex GNU GAS 
@cindex GNU GAS [assembler]
Second, depending on your platform, you may need "GAS", the GNU assembler,
or the GNU linker (see next question).

@cindex GNU gdb
Finally, while it is not required, you'll almost certainly want the GNU
debugger, gdb.  The latest version is
4.16, released April 22, 1996.
Other debuggers (like dbx, for example) will normally not be able to
understand at least some of the debug information produced by g++.

@node use GNU linker?, Use GNU assembler?, what else do I need?, installation
@section Should I use the GNU linker, or should I use "collect"?

@cindex Linker
@cindex System VR3, linker
@cindex System VR4, linker
First off, for novices: special measures must be taken with C++ to arrange
for the calling of constructors for global or static objects before the
execution of your program, and for the calling of destructors at the end.
(Exception: System VR3 and System VR4 linkers, Linux/ELF, and some other
systems support user-defined
segments; g++ on these systems requires neither the GNU linker nor
collect.  So if you have such a system, the answer is that you don't
need either one, though using GNU ld does have some advantages over
the native linker in some cases).

@cindex AT&T cfront
@cindex Cfront-end
@cindex collect program
@cindex GNU linker
@cindex GNU binutils
If you have experience with AT&T's "cfront", this function is performed
there by programs named "patch" or "munch".  With GNU C++, it is performed
either by the GNU linker or by a program known as "collect".  The collect
program is part of the gcc-2.x distribution; you can obtain the GNU linker
separately as part of the "binutils" package.  The latest version of
binutils is 2.7, released July 10, 1996; 2.6 is in common use and works
well.

(To be technical, it's "collect2"; there were originally several
alternative versions of collect, and this is the one that survived).

There are advantages and disadvantages to either choice.

Advantages of the GNU linker:
@cindex GNU linker, advantages
@cindex GNU ld
@cindex ld [GNU linker]

It's faster than using collect -- collect basically runs the standard Unix
linker on your program twice, inserting some extra code after the first
pass to call the constructors.  This is a sizable time penalty for large
programs.  The GNU linker does not require this extra pass.

GNU ld reports undefined symbols using their true names, not the mangled
names (but as of 2.7.0 so does collect).

If there are undefined symbols, GNU ld reports which object file(s) refer to
the undefined symbol(s).  On some OSes (e.g. SunOS, Solaris) the native
linker does not do this, so you have to track down who's referring to
the missing symbols yourself.

As of binutils version 2.2, on systems that use the so-called "a.out"
debug format (e.g. Suns running SunOS 4.x), the GNU linker compresses
the debug symbol table considerably.  The 2.7 version adds some symbol
table compression for ELF and Solaris targets.

@cindex collect linker, advantages
Advantages of collect:

@cindex Shared libraries
If your native linker supports shared libraries, you can use shared
libraries with collect.  This used to be a strong reason @emph{not}
to use the GNU linker, but recent versions of GNU ld support linking
with shared libraries on many platforms, and creating shared libraries
on a few (such as Intel x86 systems that use ELF object format as well
as SunOS and Solaris).

@xref{shared libraries}

@cindex GNU linker, porting
The GNU linker has not been ported to as many platforms as g++ has, so you
may be forced to use collect.

If you use collect, you don't need to get something extra and figure out
how to install it; the standard gcc installation procedure will do it for you.

I used to say at this point that I don't see a clear win for either
linking alternative, but with all the improvements in the GNU linker
I think that it is now the better choice.  Take your pick.

If you run Linux, the only available linker is the GNU linker.

@node Use GNU assembler?, shared libraries, use GNU linker?, installation
@section Should I use the GNU assembler, or my vendor's assembler?

@cindex Assembler
@cindex GNU GAS
This depends on your platform and your decision about the GNU linker.  For
most platforms, you'll need to use GAS if you use the GNU linker.  For
some platforms, you have no choice; check the gcc installation notes to
see whether you must use GAS.  But you can usually use the vendor's
assembler if you don't use the GNU linker.

The GNU assembler assembles faster than many native assemblers; however,
on many platforms it cannot support the local debugging format.

It used to be that the GNU assembler couldn't handle
position-independent code on SunOS.  This is no longer true if you
have version 2.6 or newer.

On HPUX or IRIX, you must use GAS (and configure gcc with the
@code{--with-gnu-as} option) to debug your programs.  GAS is
strongly recommended particularly on the HP platform because of
limitations in the HP assembler.

The GNU assembler has been merged with the binutils
distribution, so the GNU assembler and linker are now together in
this package (as of binutils version 2.5.1).

On Linux the assembler is the GNU assembler.

@node shared libraries, repository, Use GNU assembler?, installation
@section How do I build shared libraries with g++?

For gcc-2.7.0 and later, building C++ shared libraries should work fine
on supported platforms (HPUX 9+, IRIX 5+, DEC UNIX (formerly OSF/1),
SGI/IRIX, AIX, SunOS 4, Linux/ELF and all targets using SVR4-style ELF shared
libraries).  There are two separate issues: building libg++ as a shared
library, and making your own shared libraries.  For libg++ it is simply
a matter of giving the @code{--enable-shared} option to the configure
program.  When compiling your own code for shared libraries you
generally
must use the @code{-fPIC} flag to get position-independent code.

@cindex -shared flag of gcc

If your shared library contains global or static objects with
constructors, then make sure to use @code{gcc -shared}, not
@code{ld}, to create the shared library.  This will make sure
that any processor-specific magic needed to execute the constructors
is included.

In theory, constructors for objects in your shared library should be
called when the library is opened (by dlopen or equivalent).  This
does not work on some platforms (e.g. SunOS4; it does work on Solaris
and ELF systems such as Linux): on the broken platforms, the
constructors are not called correctly.

David Nilsen has suggested the following workaround:

The thing to realize is that if you link your dynamic module with the
@code{-shared} flag, the collect program nicely groups all the static
ctors/dtors for you into a list and sets up a function that will call
them (Note: this means that this trick won't work if you use the GNU
linker without collect (@pxref{use GNU linker?}).

The magic is knowing these function names.  Currently, they're called:

@example
_GLOBAL__DI   <-- calls all module constructors
_GLOBAL__DD   <-- calls all module destructors
@end example

[ possibly the leading underscore will differ between platforms: jbuck ]

Therefore, if you make a wrapper around dlopen that looks up the
symbol @code{_GLOBAL__DI} (or @code{__GLOBAL__DI} on SunOS4 machines), and
calls it, you'll simulate getting the constructors called.

You also need to set up the destructors to be called as well, so you
need to put a wrapper around dlclose, which will call the
@code{_GLOBAL__DD} function in the module when/if it's unloaded.

Lastly, to get things 100% correct, you need to set up the destructors
to also be called if the module is not unloaded, but the main program
exits.  I do this by registering a single function with @code{atexit()} that
calls all the destructors left in dynamically loaded modules.

@cindex Shared version of libg++
Check the file @file{README.SHLIB} from the libg++ distribution for more
about making and using shared libraries.

@cindex Shared libraries with HP

A patch is needed to build shared versions of version 2.7.2 of libg++
and libstdc++ on the HP-PA architecture.  You can find the patch at
@file{ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix}.