OS/2 Shareware BBS: 22 gnu/22-gnu.zip/GNUGPPFQ.ZIP/GPPFAQ

Internet Message Format | 1993-02-02 | 56KB

From: [e-mail] (Joe Buck)
Subject: FAQ for g++ and libg++, plain text version [Revised 15 Jan 1993]
Date: 1 Feb 93 09:00:09 GMT
Organization: University of California, Berkeley
Lines: 647

Archive-name: g++-FAQ/plain
Last-modified: 15 Jan 1993
Frequency: bimonthly

[ this is the plain text version, the parent is the texinfo version ]
Preface
*******

   This is a list of frequently asked questions for g++ users; thanks
to all those who sent suggestions for improvements.

   You can obtain the latest version of this file by anonymous FTP from
site forney.berkeley.edu [128.32.240.77], in the pub directory.

   I'm looking for new questions, better answers, or both.  One thing
that's missing is a section on templates and template problems with
g++; I'm looking for contributions on this score.  You can mail
comments, suggestions, flames, etc. to [e-mail].

   This FAQ is intended to supplement, not replace, Marshall Cline's
excellent FAQ for comp.lang.c++.  Especially if g++ is the first C++
compiler you've ever used, the question "How do I do <X> with g++?" is
probably really "How do I do <X> in C++?".  You can obtain the C++ FAQ
by anonymous FTP from sun.soe.clarkson.edu [128.153.12.3], in the file
~ftp/pub/C++/FAQ.  (There is also a mail server for that FAQ, but it
seems to be broken).


Obtaining Source Code
*********************


How do I get a copy of g++ for Unix?
====================================

   First, you may already have it if you have gcc for your platform;
g++ and gcc are combined now (as of gcc version 2.0).

   You can get g++ from a friend who has a copy, by anonymous FTP or
UUCP, or by ordering a tape or CD-ROM from the Free Software
Foundation.

   The Free Software Foundation is a nonprofit organization that
distributes software and manuals to raise funds for more GNU
development.  Getting your copy from the FSF contributes directly to
paying staff to develop GNU software.  CD-ROMs cost $100 if an
individual is buying, or $400 if an organization is buying.  Tapes
cost around $200 depending on media type.  I recommend asking for
version 2, not version 1, of g++.

   For more information about ordering from the FSF, contact
[e-mail] or phone [phone].

   Here is a list of anonymous FTP archive sites for GNU software.

     Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
     Australia: archie.au:gnu
     Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
         ftp.informatik.rwth-aachen.de:pub/gnu,
         nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
         ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
         ftp.diku.dk, ftp.eunet.ch, archive.eu.net
     United States: wuarchive.wustl.edu, ftp.cs.widener.edu,
         uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
         ftp.uu.net:packages/gnu

   The "official site" is prep.ai.mit.edu, but your transfer will
probably go faster if you use one of the above machines.

   If you use the HP Precision Architecture (HP-9000/7xx and
HP-9000/8xx) and you want to use debugging, you'll need to grab
special versions of GAS and GDB from the University of Utah, site
jaguar.cs.utah.edu.  You no longer need to use their modified gcc/g++
to use debugging (although they have a version called gcc-2.3.3.u1
with a couple of added patches).  Look in the "/dist" directory.  I
understand that their gdb code is being folded into (the not yet
released) gdb-4.8.  A non-standard debug format is used, since HP
considers their debug format a trade secret.

   UUNET customers can get GNU sources from UUNET via UUCP.  UUCP-only
sites can get GNU sources by "anonymous UUCP" from site "osu-cis" at
Ohio State University.  You pay for the long-distance call to OSU; the
price isn't too bad on weekends at 9600 bps.  Send mail to
[e-mail] or osu-cis!uucp for more information.

   OSU lines are often busy.  If you're in the USA, and are willing to
spend more money, you can get sources via UUCP from UUNET using their
900 number: 1-900-GOT-SRCS (900 numbers don't work internationally).
You will be billed $0.50/minute by your phone company.

   Don't forget to retrieve libg++ as well!


How do I get a copy of g++ for (some other platform)?
=====================================================

   The standard gcc/g++ distribution includes VMS support.  Since the
FSF people don't use VMS, it's likely to be somewhat less solid than
the Unix version.  Precompiled copies of g++ and libg++ in
VMS-installable form are available by FTP from mango.rsmas.miami.edu.

   DJ Delorie has ported gcc/g++ to MS-DOS; this port is popularly
known as "DJGPP" (the P's stand for "plus").  It can be found on many
FTP archive sites; its "home" is on grape.ecs.clarkson.edu, directory
~ftp/pub/msdos/djgpp.  Make sure you're retrieving the current version,
which should indicate that it is a port of gcc-2.2.2 (2.3.1 through
2.3.3 have been released since then, but I don't think the DOS port is
done yet).  It is also available on site wuarchive.wustl.edu, in
directory mirrors/msdos/djgpp, and many other places as well.

   For information on Amiga ports of gcc/g++, retrieve the file
/pub/gnu/MicrosPorts/Amiga from prep.ai.mit.edu, or write to Leonard
Norrgard <[e-mail]>, who I hope won't be too upset that I
mentioned his name here.

   A port of gcc-2.3.1 to the Atari ST can be found on the site
"atari.archive.umich.edu", under /atari/Gnustuff/Tos, along with many
other GNU programs.  See the FAQ for the Usenet group
"comp.sys.atari.st" for more information.

   There are two different ports of gcc-2.2.2 (and g++) to OS/2, the
so-called EMX port, which requires a particular Unix emulator, and a
port called "gcc/2", which runs native.  The latter port uses a rather
buggy port of the BSD libc.  For more information ask around on
comp.os.os2.programmer.  gcc/2 can be obtained by FTP from

     ftp-os2.nmsu.edu (128.123.35.151) in /pub/os2/2.0/programming/gcc2-222
     luga.latrobe.edu.au (131.172.2.2) in /pub/os2/2.0/programming/gcc2-222

   Eberhard Mattes did the EMX port.  Tevor Lampre did the gcc/2 port.
Their addresses are [e-mail] and
[e-mail], repectively.

   Because the legal policies of Apple threaten the long-term goals of
FSF, as well as the concept of free software, no support will be lent
to efforts to port GNU software to Macintosh or other Apple hardware.


But I can only find g++-1.42!
=============================

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

   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".


What is the latest version of gcc, g++, and libg++?
===================================================

   The latest "2.x" version of gcc/g++ is 2.3.3, released Dec 26, 1992.
The latest version of libg++ is 2.3, released Dec 9, 1992.

   For some non-Unix platforms, 2.2.2 may be the latest compiler that
has been ported.  libg++ 2.3 will not compile with gcc-2.2.2.

   The latest "1.x" version of gcc is 1.42, and the latest "1.x"
version of g++ is 1.42.0.


Installation Issues and Problems
********************************


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?"

   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 g++-2.3.3, as
it is the version that is being actively maintained.

   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.


OK, I've obtained gcc; what else do I need?
===========================================

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

   Second, depending on your platform, you may need "gas", the GNU
assembler, or the GNU linker (see next question).


Should I use the GNU linker, or should I use "collect"?
=======================================================

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

   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.

   (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:

   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.

   If there are undefined symbols, GNU ld reports which object file(s)
refer to the undefined symbol(s).

   Advantages of collect:

   If your native linker supports shared libraries, you can use shared
libraries with collect.  The GNU linker does not (yet) support shared
libraries.

   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.

   In conclusion, I don't see a clear win for either alternative at
this point.  Take your pick.


Should I use the GNU assembler, or my vendor's assembler?
=========================================================

   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.


Should I use the GNU C library?
===============================

   At this point in time, no.  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.


Problems building libg++ on Ultrix
==================================

   "I am having trouble building libg++-2.2 on Ultrix [and possibly
other systems].  I get errors referring to "dummy.o".  Help!"

   (The errors on Ultrix end with something like

     ldopen: cannot open dummy.o
     nm: Error: cannot open dummy.o
     ldopen: cannot open dummy.o
     nm: Error: cannot open dummy.o
     nm failed to find FUNC in dummy.o!
     sh: -1: bad number
     *** Error code 1

and there may be similar problems on other systems).

   The fix for this is to make libg++ by saying "make CC=gcc".


Mysterious undefined symbol with libg++-2.3
===========================================

   [ From James Montebello ([e-mail]) ] "After I
upgraded g++ to the latest version, stuff that linked perfectly before
now has unresolved externals like:

     __vt$10ostrstream$7ios

   but ios::ostrstream is in the library. What gives?"

   [ From Brendan Kehoe ([e-mail]) ]

   The 2.3.3 release of gcc (g++) included a fix for how virtual table
names are mangled.  This creates an inconsistency between names the
compiler generates, and the names in any libg++ created with a
compiler before 2.3.3.  For example, one of the most common problems
people will face as a result of this change will be an error that the
symbol `__vt$10ostrstream$3ios' is undefined at link-time.

   It is necessary to build a new libg++.a with the latest (2.3.3)
compiler to sync things back up.  This would probably also be a good
opportunity to upgrade to the libg++ 2.3 release if you haven't yet.

   Thanks, and my apologies for any inconvenience this may cause.


User Problems
*************


Linker reports undefined symbols for static data members
========================================================

   "g++ reports undefined symbols for all my static data members when
I link, even though the program works correctly for compiler XYZ.
What's going on?"

   The problem is almost certainly that you don't give definitions for
your static data members.  If you have

     class Foo {
         ...
         void method();
         static int bar;
     };

   you have only declared that there is an int named Foo::bar and a
member function named Foo::method that is defined somewhere.  You
still need to defined BOTH method() and bar in some source file.
According to the draft ANSI standard, you must supply an initializer,
such as

     int Foo::bar = 0;

in one (and only one) source file.


g++ won't accept the placement new syntax.
==========================================

   "I have a program that uses the "placement syntax" of operator new,
e.g.

        new (somewhere) T;

and g++ won't accept it."

   Up until version 2.3.1, g++ accepted an alternate form of the
placement syntax, for historical reasons; use

        new {somewhere} T;

if you are using g++-2.2.2 or older.

   As of 2.3.1, g++ finally fixed this, using the standard ARM syntax
for "placement new".  A few remaining glitches were fixed in 2.3.2.
The only remaining problem is with declarators for pointers to
functions;

     new (void (*)(int));  // confuses gcc 2.3.2
     new (a) (void (*)(int)); // ditto

   These can be worked around with a typedef:

     typedef void (*fun)(int);
     new fun;
     new (a) fun;


I think I have found a bug in g++.
==================================

   "I think I have found a bug in g++, but I'm not sure.  How do I
know, and who should I tell?"

   First, see the excellent section on bugs and bug reports in the gcc
manual (which is included in the gcc distribution).  As a short
summary of that section: if the compiler gets a fatal signal, for any
input, it's a bug.  Same thing for producing invalid assembly code.

   I will add some extra notes that are C++-specific, since the notes
from gcc are generally C-specific.

   First, mail your bug report to "[e-mail]".  You may
also post to gnu.bug.g++, but it's better to use mail, particularly if
you have any doubt as to whether your news software generates correct
reply addresses.  Don't mail C++ bugs to [e-mail].

   If your bug involves libg++ rather than the compiler, mail to
[e-mail].  If you're not sure, you could send your
bug to both lists.

   Second, if your program does one thing, and you think it should do
something else, it is best to consult a good reference if in doubt.
The standard reference is "The Annotated C++ Reference Manual", by
Ellis and Stroustrup (copyright 1990, ISBN #0-201-51459-1).  This is
what they're talking about on the net when they refer to "the ARM".

   The reference manual, without annotations, also appears in
Stroustrup's "The C++ Programming Language, Second Edition" (copyright
1991, ISBN #0-201-53992-6).  Both books are published by
Addison-Wesley.

   Note that the behavior of (any version of) AT&T's "cfront" compiler
is NOT the standard for the language.


Porting programs from other compilers to g++
============================================

   "I have a program that runs on <some other C++ compiler>, and I want
to get it running under g++.  Is there anything I should watch out
for?"

   First, see the questions on placement new syntax and static data
members.

   There are two other reasons why a program that worked under one
compiler might fail under another: your program may depend on the
order of evaluation of side effects in an expression, or it may depend
on the lifetime of a temporary (you may be assuming that a temporary
object "lives" longer than the standard guarantees).  As an example of
the first:

     void func(int,int);

     int i = 3;
     func(i++,i++);

   Novice programmers think that the increments will be evaluated in
strict left-to-right order.  Neither C nor C++ guarantees this; the
second increment might happen first, for example.  func might get 3,4,
or it might get 4,3.

   The second problem often happens with classes like the libg++ String
class.  Let's say I have

     String func1();
     void func2(const char*);

   and I say

     func2(func1());

   because I know that class String has an "operator const char*".  So
what really happens is

     func2(func1().convert());

   where I'm pretending I have a convert() method that is the same as
the cast.  This is unsafe, because the temporary String object may be
deleted after its last use (the call to the conversion function),
leaving the pointer pointing to garbage, so by the time func2 is
called, it gets an invalid argument.

   If you think this is ugly, you should know that the ANSI C++
committee is STILL debating the lifetime-of-temporaries problem.

   For now, the safe way to write such code is to give the temporary a
name, which forces it to live until the end of the scope of the name.
For example:

     String& tmp = func1();
     func2(tmp);

   Finally, like all compilers (but especially C++ compilers, it
seems), g++ has bugs, and you may have tweaked one.


Why does g++ mangle names differently from other C++ compilers?
===============================================================

   See the answer to the next question.


Why can't g++ code link with code from other C++ compilers?
===========================================================

   "Why can't I link g++-compiled programs against libraries compiled
by some other C++ compiler?"

   Some people think that, if only the FSF and Cygnus Support folks
would stop being stubborn and mangle names the same way that, say,
cfront does, then any g++-compiled program would link successfully
against any cfront-compiled library and vice versa.  Name mangling is
the least of the problems.  Compilers differ as to how objects are
laid out, how multiple inheritance is implemented, how virtual
function calls are handled, and so on, so if the name mangling were
made the same, your programs would link against libraries provided
from other compilers but then crash when run.  For this reason, the
ARM *encourages* compiler writers to make their name mangling
different from that of other compilers for the same platform.
Incompatible libraries are then detected at link time, rather than at
run time.


What documentation exists for g++ 2.x?
======================================

   Almost none.  The gcc manual describes the C front end, and also
the back end, which is shared by the C++ compiler, but there is almost
no documentation for the C++ front end.  There is a Unix-style manual
entry, "g++.1", in the gcc-2.x distribution; this describes the extra
command-line options that g++ supports, and the #pragma interface and
#pragma implementation directives.

   A draft of a document describing the g++ internals appears in the
2.3.3 distribution (called g++int.texi); it is still incomplete.

   Work is proceeding on a user g++ document; with luck it will appear
in the next release.


What are the differences between g++ and the ARM specification of C++?
======================================================================

   The chief thing missing from g++ that is in the ARM is exceptions
(the other major compilers do not have exceptions either).  There are
bits and pieces of exception code present, but it is not presently
usable.

   The template implementation is still new.  The implementation in
2.3.3 represents a considerable improvement over that of previous
releases, however.  Still, it has many bugs.

   g++ does not implement a separate pass to instantiate template
functions and classes at this point; for this reason, it will not
work, for the most part, to declare your template functions in one
file and define them in another.  The compiler will need to see the
entire definition of the function, and will generate a static copy of
the function in each file in which it is used.

   As with any beta-test compiler, there are bugs.  You can help
improve the compiler by submitting detailed bug reports.

   [A full bug list would be very long indeed, so I won't put one here.
I may add a list of frequently-reported bugs and "non-bugs" like the
static class members issue mentioned above].


Will g++ compile InterViews?  The NIH class library?
====================================================

   The NIH class library uses a non-portable, compiler-dependent hack
to initialize itself, which makes life difficult for g++ users.  It
will not work without modification, and I don't know what modifications
are required or whether anyone has done them successfully.

   Brendan Kehoe of Cygnus Support is working on getting NIHCL to
build with g++.  He says, "The NIHCL release will hopefully contain
patches to gcc 2.3 to let it build."

   [ From Steinar Bang <[e-mail]>]

   InterViews 3.1 compiles and runs with gcc-2.3.3 and libg++-2.3,
except that the "doc" application immediately dumps core when you try
to run it.  There is also a small glitch with idraw.

   There is a patch for InterViews 3.1 from Johan Garpendahl
<[e-mail]> available for FTP from site "ugle.unit.no".  It is
in the file

   /pub/X11/contrib/InterViews/g++/3.1-beta3-patch.

   This fixes two things: the Doc coredump, and the pattern menu of
idraw.  Read the instructions at the start of the file.


Debugging on SVR4 systems
=========================

   "When I use the -g flag on C++ code on a System V Release 4 system,
I get lots of undefined symbols at link time.  Why?  Help!"

   [From Ron Guilmette:] The changes needed to get the g++ front-end
to generate proper DWARF style debugging information for System V
Release 4 are not yet completed, nor will they be until g++ version
2.4 (at the earliest).

   There is nothing that you (as an end-user) can do to correct this
problem.  (It is actually *many* problems, and they are all very
complex.)  Until the g++ maintainers have time to fix this, you should
simply *avoid* using the -g option when using g++ on SVR4.


What are the rules for shipping code built with g++ and libg++?
***************************************************************

   "Is it is possible to distribute programs for profit that are
created with g++ and use the g++ libraries?"

   I am not a lawyer, and this is not legal advice.  In any case, I
have little interest in telling people how to violate the spirit of the
GNU licenses without violating the letter.  This section tells you how
to comply with the intention of the GNU licenses as best I understand
them.

   The FSF has no objection to your making money.  Its only interest
is that source code to their programs, and libraries, and to modified
versions of their programs and libraries, is always available.

   The short answer is that you do not need to release the source to
your program, but you can't just ship a stripped executable either.

   Compiling your code with a GNU compiler does not affect its
copyright; it is still yours.  However, in order to ship code that
links in a GNU library such as libg++ there are certain rules you must
follow.  The rules are described in the file COPYING.LIB that
accompanies gcc distributions; it is also included in the libg++
distribution.  See that file for the exact rules.  The agreement is
called the Library GNU Public License or LGPL.  It is much "looser"
than the GNU Public License, or GPL, that covers must GNU programs.

   Here's the deal: let's say that you use some version of libg++,
completely unchanged, in your software, and you want to ship only a
binary form of your code.  You can do this, but there are several
special requirements.  If you want to use libg++ but ship only object
code for your code, you have to ship source for libg++ (or ensure
somehow that your customer already has the source for the exact
version you are using), and ship your application in linkable form.
You cannot forbid your customer from reverse-engineering or extending
your program by exploiting its linkable form.

   Furthermore, if you modify libg++ itself, you must provide source
for your modifications (making a derived class does not count as
modifying the library -- that is "a work that uses the library").


--
Joe Buck    [e-mail]

Xref: ukelele comp.lang.c++:475 news.answers:525
Path: ukelele!pyrdc!gossip.pyramid.com!decwrl!ames!agate!usenet
From: [e-mail] (Joe Buck)
Newsgroups: gnu.g++.help,comp.lang.c++,news.answers,comp.answers
Subject: FAQ for g++ and libg++, texinfo version [Revised 15 Jan 1993]
Message-ID: <[e-mail]>
Date: 1 Feb 93 09:00:06 GMT
Expires: +1 month
References: <[e-mail]>
Followup-To: poster
Organization: University of California, Berkeley
Lines: 710
Approved: [e-mail]
Supersedes: <[e-mail]>
NNTP-Posting-Host: ohm.berkeley.edu

Archive-name: g++-FAQ/texi
Last-modified: 15 Jan 1993
Frequency: bimonthly

[ This is the texinfo version.  If you don't know what texinfo is,
  then you probably want to use the companion plain-text version. ]

------------- cut here ----------------------------------------------
\input texinfo.tex      @c -*-texinfo-*-
@c %**start of header
@setfilename g++FAQ.info
@settitle Frequently asked questions about the GNU C++ compiler
@setchapternewpage off
@c version: %W% %G%
@c %**end of header

@finalout

@titlepage
@title G++ FAQ
@subtitle Frequently asked questions about the GNU C++ compiler
@subtitle January 5, 1993
@sp 1
@author Joe Buck
@page
@end titlepage

@node Top, getting g++, (dir), (dir)
@unnumbered Preface

This is a list of frequently asked questions for g++ users; thanks to
all those who sent suggestions for improvements.

You can obtain the latest version of this file by anonymous FTP from
site forney.berkeley.edu [128.32.240.77], in the pub directory.

I'm looking for new questions, better answers, or both.  One thing that's
missing is a section on templates and template problems with g++; I'm
looking for contributions on this score.  You can mail comments,
suggestions, flames, etc. to jbuck@@ohm.berkeley.edu.

This FAQ is intended to supplement, not replace, Marshall Cline's
excellent FAQ for comp.lang.c++.  Especially if g++ is the first C++
compiler you've ever used, the question "How do I do <X> with g++?"
is probably really "How do I do <X> in C++?".  You can obtain the
C++ FAQ by anonymous FTP from sun.soe.clarkson.edu [128.153.12.3],
in the file ~ftp/pub/C++/FAQ.  (There is also a mail server for that
FAQ, but it seems to be broken).

@menu
* getting g++::                 Obtaining Source Code
* installation::                Installation Issues and Problems
* User Problems::               User Problems
* legalities::                  What are the rules for shipping code built with g++ and libg++?
@end menu

@node getting g++, installation, Top, Top
@chapter Obtaining Source Code

@menu
* g++ for Unix::                How do I get a copy of g++ for Unix?
* g++ for other platforms::     How do I get a copy of g++ for (some other platform)?
* 1.x vs 2.x versions::         But I can only find g++-1.42!
* latest versions::             What is the latest version of gcc, g++, and libg++?
@end menu

@node g++ for Unix, g++ for other platforms, getting g++, getting g++
@section How do I get a copy of g++ for Unix?

First, you may already have it if you have gcc for your platform;
g++ and gcc are combined now (as of gcc version 2.0).

You can get g++ from a friend who has a copy, by anonymous FTP or
UUCP, or by ordering a tape or CD-ROM from the Free Software
Foundation.

The Free Software Foundation is a nonprofit organization that
distributes software and manuals to raise funds for more GNU
development.  Getting your copy from the FSF contributes directly to
paying staff to develop GNU software.  CD-ROMs cost $100 if an
individual is buying, or $400 if an organization is buying.  Tapes
cost around $200 depending on media type.  I recommend asking for
version 2, not version 1, of g++.

For more information about ordering from the FSF, contact
gnu@@prep.ai.mit.edu or phone [phone].

Here is a list of anonymous FTP archive sites for GNU software.

@example
Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
Australia: archie.au:gnu
Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
    ftp.informatik.rwth-aachen.de:pub/gnu,
    nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
    ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
    ftp.diku.dk, ftp.eunet.ch, archive.eu.net
United States: wuarchive.wustl.edu, ftp.cs.widener.edu,
    uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
    ftp.uu.net:packages/gnu
@end example

The "official site" is prep.ai.mit.edu, but your transfer will probably
go faster if you use one of the above machines.

If you use the HP Precision Architecture (HP-9000/7xx and HP-9000/8xx)
and you want to use debugging, you'll need to grab special versions of
GAS and GDB from the University of Utah, site jaguar.cs.utah.edu.  You
no longer need to use their modified gcc/g++ to use debugging (although
they have a version called gcc-2.3.3.u1 with a couple of added patches).
Look in the "/dist" directory.  I understand that their gdb code is
being folded into (the not yet released) gdb-4.8.  A non-standard debug
format is used, since HP considers their debug format a trade secret.

UUNET customers can get GNU sources from UUNET via UUCP.
UUCP-only sites can get GNU sources by "anonymous UUCP" from site
"osu-cis" at Ohio State University.  You pay for the long-distance call
to OSU; the price isn't too bad on weekends at 9600 bps.  Send mail to
uucp@@cis.ohio-state.edu or osu-cis!uucp for more information.

OSU lines are often busy.  If you're in the USA, and are willing to spend
more money, you can get sources via UUCP from UUNET using their 900 number:
1-900-GOT-SRCS (900 numbers don't work internationally).  You will be
billed $0.50/minute by your phone company.

Don't forget to retrieve libg++ as well!

@node g++ for other platforms, 1.x vs 2.x versions, g++ for Unix, getting g++
@section How do I get a copy of g++ for (some other platform)?

The standard gcc/g++ distribution includes VMS support.  Since the
FSF people don't use VMS, it's likely to be somewhat less solid than
the Unix version.  Precompiled copies of g++ and libg++ in VMS-installable
form are available by FTP from mango.rsmas.miami.edu.

DJ Delorie has ported gcc/g++ to MS-DOS; this port is popularly known as
"DJGPP" (the P's stand for "plus").  It can be found on many FTP archive
sites; its "home" is on grape.ecs.clarkson.edu, directory
~ftp/pub/msdos/djgpp.  Make sure you're retrieving the current version,
which should indicate that it is a port of gcc-2.2.2 (2.3.1 through 2.3.3 have
been released since then, but I don't think the DOS port is done yet).  It
is also available on site wuarchive.wustl.edu, in directory
mirrors/msdos/djgpp, and many other places as well.

For information on Amiga ports of gcc/g++, retrieve the file
/pub/gnu/MicrosPorts/Amiga from prep.ai.mit.edu, or write
to Leonard Norrgard <vinsci@@nic.funet.fi>, who I hope won't be too upset
that I mentioned his name here.

A port of gcc-2.3.1 to the Atari ST can be found on the site
``atari.archive.umich.edu'', under /atari/Gnustuff/Tos, along with many
other GNU programs.  See the FAQ for the Usenet group
``comp.sys.atari.st'' for more information.

There are two different ports of gcc-2.2.2 (and g++) to OS/2, the
so-called EMX port, which requires a particular Unix emulator, and
a port called ``gcc/2'', which runs native.  The latter port uses
a rather buggy port of the BSD libc.  For more information ask
around on comp.os.os2.programmer.  gcc/2 can be obtained by FTP
from

@example
ftp-os2.nmsu.edu (128.123.35.151) in /pub/os2/2.0/programming/gcc2-222
luga.latrobe.edu.au (131.172.2.2) in /pub/os2/2.0/programming/gcc2-222
@end example

Eberhard Mattes did the EMX port.  Tevor Lampre did the gcc/2 port.
Their addresses are mattes@@azu.informatik.uni-stuttgart.de and
mmtl@@cc.flinders.edu.au, repectively.

Because the legal policies of Apple threaten the long-term goals of FSF,
as well as the concept of free software, no support will be lent to
efforts to port GNU software to Macintosh or other Apple hardware.

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

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

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".

@menu
* latest versions::             What is the latest version of gcc, g++, and libg++?
@end menu

@node latest versions,  , 1.x vs 2.x versions, getting g++
@section What is the latest version of gcc, g++, and libg++?

The latest "2.x" version of gcc/g++ is 2.3.3, released Dec 26, 1992.
The latest version of libg++ is 2.3, released Dec 9, 1992.

For some non-Unix platforms, 2.2.2 may be the latest compiler that
has been ported.  libg++ 2.3 will not compile with gcc-2.2.2.

The latest "1.x" version of gcc is 1.42, and the latest "1.x" version of
g++ is 1.42.0.

@node installation, User Problems, getting g++, Top
@chapter Installation Issues and Problems

@menu
* gcc-2 + g++-1::               I can't build g++ 1.x.y with gcc-2.x.y!
* what else do I need?::        OK, I've obtained gcc; what else do I need?
* use GNU linker?::             Should I use the GNU linker, or should I use "collect"?
* Use GNU assembler?::          Should I use the GNU assembler, or my vendor's assembler?
* Use GNU C library?::          Should I use the GNU C library?
* Problems building libg++ on Ultrix::  Problems building libg++ on Ultrix
* Mysterious undefined symbol::  Mysterious undefined symbol with libg++-2.3
@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?''

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 g++-2.3.3, as it
is the version that is being actively maintained.

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?

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

Second, depending on your platform, you may need "gas", the GNU assembler,
or the GNU linker (see next question).

@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"?

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

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.

(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:

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.

If there are undefined symbols, GNU ld reports which object file(s) refer to
the undefined symbol(s).

Advantages of collect:

If your native linker supports shared libraries, you can use shared
libraries with collect.  The GNU linker does not (yet) support shared
libraries.

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.

In conclusion, I don't see a clear win for either alternative at this
point.  Take your pick.

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

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.

@node Use GNU C library?, Problems building libg++ on Ultrix, Use GNU assembler?, installation
@section Should I use the GNU C library?

At this point in time, no.  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 Problems building libg++ on Ultrix, Mysterious undefined symbol, Use GNU C library?, installation
@section Problems building libg++ on Ultrix

``I am having trouble building libg++-2.2 on Ultrix [and possibly other
systems].  I get errors referring to "dummy.o".  Help!''

(The errors on Ultrix end with something like

@example
ldopen: cannot open dummy.o
nm: Error: cannot open dummy.o
ldopen: cannot open dummy.o
nm: Error: cannot open dummy.o
nm failed to find FUNC in dummy.o!
sh: -1: bad number
*** Error code 1
@end example

@noindent
and there may be similar problems on other systems).

The fix for this is to make libg++ by saying "make CC=gcc".

@node Mysterious undefined symbol,  , Problems building libg++ on Ultrix, installation
@section Mysterious undefined symbol with libg++-2.3

[ From James Montebello (james@@ignatz.bridge.COM) ]
``After I upgraded g++ to the latest version, stuff that linked
perfectly before now has unresolved externals like:

@example
__vt$10ostrstream$7ios
@end example

but ios::ostrstream is in the library. What gives?''

[ From Brendan Kehoe (brendan@@cygnus.com) ]

The 2.3.3 release of gcc (g++) included a fix for how virtual table
names are mangled.  This creates an inconsistency between names the
compiler generates, and the names in any libg++ created with a
compiler before 2.3.3.  For example, one of the most common problems
people will face as a result of this change will be an error that the
symbol `__vt$10ostrstream$3ios' is undefined at link-time.

It is necessary to build a new libg++.a with the latest (2.3.3)
compiler to sync things back up.  This would probably also be a good
opportunity to upgrade to the libg++ 2.3 release if you haven't yet.

Thanks, and my apologies for any inconvenience this may cause.

@node User Problems, legalities, installation, Top
@chapter User Problems

@menu
* static data members::         Linker reports undefined symbols for static data members
* placement new syntax::        g++ won't accept the placement new syntax.
* bug reports::                 I think I have found a bug in g++.
* porting to g++::              Porting programs from other compilers to g++
* name mangling::               Why does g++ mangle names differently from other C++ compilers?
* problems linking with other libraries::  Why can't g++ code link with code from other C++ compilers?
* documentation::               What documentation exists for g++ 2.x?
* agreement with standards::    What are the differences between g++ and the ARM specification of C++?
* compiling standard libraries::  Will g++ compile InterViews?  The NIH class library?
* debugging on SVR4 systems::   Debugging on SVR4 systems
@end menu

@node static data members, placement new syntax, User Problems, User Problems
@section Linker reports undefined symbols for static data members

``g++ reports undefined symbols for all my static data members when I link,
even though the program works correctly for compiler XYZ.  What's going on?''

The problem is almost certainly that you don't give definitions for
your static data members.  If you have

@example
class Foo @{
    ...
    void method();
    static int bar;
@};
@end example

you have only declared that there is an int named Foo::bar and a member
function named Foo::method that is defined somewhere.  You still need to
defined BOTH method() and bar in some source file.  According to the draft
ANSI standard, you must supply an initializer, such as

@example
int Foo::bar = 0;
@end example

@noindent
in one (and only one) source file.

@node placement new syntax, bug reports, static data members, User Problems
@section g++ won't accept the placement new syntax.

``I have a program that uses the "placement syntax" of operator new,
e.g.

@example
   new (somewhere) T;
@end example

@noindent
and g++ won't accept it.''

Up until version 2.3.1, g++ accepted an alternate form of the placement
syntax, for historical reasons; use

@example
   new @{somewhere@} T;
@end example

@noindent
if you are using g++-2.2.2 or older.

As of 2.3.1, g++ finally fixed this, using the standard ARM syntax for
"placement new".  A few remaining glitches were fixed in 2.3.2.  The
only remaining problem is with declarators for pointers to functions;

@example
new (void (*)(int));  // confuses gcc 2.3.2
new (a) (void (*)(int)); // ditto
@end example

These can be worked around with a typedef:

@example
typedef void (*fun)(int);
new fun;
new (a) fun;
@end example

@node bug reports, porting to g++, placement new syntax, User Problems
@section I think I have found a bug in g++.

``I think I have found a bug in g++, but I'm not sure.  How do I know,
and who should I tell?''

First, see the excellent section on bugs and bug reports in the gcc manual
(which is included in the gcc distribution).  As a short summary of that
section: if the compiler gets a fatal signal, for any input, it's a bug.
Same thing for producing invalid assembly code.

I will add some extra notes that are C++-specific, since the notes from
gcc are generally C-specific.

First, mail your bug report to "bug-g++@@prep.ai.mit.edu".  You may also
post to gnu.bug.g++, but it's better to use mail, particularly if you
have any doubt as to whether your news software generates correct reply
addresses.  Don't mail C++ bugs to bug-gcc@@prep.ai.mit.edu.

If your bug involves libg++ rather than the compiler, mail to
bug-libg++@@prep.ai.mit.edu.  If you're not sure, you could send your bug
to both lists.

Second, if your program does one thing, and you think it should do
something else, it is best to consult a good reference if in doubt.  The
standard reference is "The Annotated C++ Reference Manual", by Ellis and
Stroustrup (copyright 1990, ISBN #0-201-51459-1).  This is what they're
talking about on the net when they refer to ``the ARM''.

The reference manual, without annotations, also appears in Stroustrup's
"The C++ Programming Language, Second Edition" (copyright 1991, ISBN
#0-201-53992-6).  Both books are published by Addison-Wesley.

Note that the behavior of (any version of) AT&T's "cfront" compiler is
NOT the standard for the language.

@node porting to g++, name mangling, bug reports, User Problems
@section Porting programs from other compilers to g++

``I have a program that runs on <some other C++ compiler>, and I want
to get it running under g++.  Is there anything I should watch out
for?''

First, see the questions on placement new syntax and static data members.

There are two other reasons why a program that worked under one compiler
might fail under another: your program may depend on the order of
evaluation of side effects in an expression, or it may depend on the
lifetime of a temporary (you may be assuming that a temporary object
"lives" longer than the standard guarantees).  As an example of the
first:

@example
void func(int,int);

int i = 3;
func(i++,i++);
@end example

Novice programmers think that the increments will be evaluated in strict
left-to-right order.  Neither C nor C++ guarantees this; the second
increment might happen first, for example.  func might get 3,4, or it
might get 4,3.

The second problem often happens with classes like the libg++ String
class.  Let's say I have

@example
String func1();
void func2(const char*);
@end example

and I say

@example
func2(func1());
@end example

because I know that class String has an "operator const char*".  So what
really happens is

@example
func2(func1().convert());
@end example

where I'm pretending I have a convert() method that is the same as the
cast.  This is unsafe, because the temporary String object may be deleted
after its last use (the call to the conversion function), leaving the
pointer pointing to garbage, so by the time func2 is called, it gets an
invalid argument.

If you think this is ugly, you should know that the ANSI C++ committee is
STILL debating the lifetime-of-temporaries problem.

For now, the safe way to write such code is to give the temporary a name,
which forces it to live until the end of the scope of the name. For
example:

@example
String& tmp = func1();
func2(tmp);
@end example

Finally, like all compilers (but especially C++ compilers, it seems),
g++ has bugs, and you may have tweaked one.

@node name mangling, problems linking with other libraries, porting to g++, User Problems
@section Why does g++ mangle names differently from other C++ compilers?

See the answer to the next question.

@node problems linking with other libraries, documentation, name mangling, User Problems
@section Why can't g++ code link with code from other C++ compilers?

``Why can't I link g++-compiled programs against libraries compiled by
some other C++ compiler?''

Some people think that,
if only the FSF and Cygnus Support folks would stop being
stubborn and mangle names the same way that, say, cfront does, then any
g++-compiled program would link successfully against any cfront-compiled
library and vice versa.  Name mangling is the least of the problems.
Compilers differ as to how objects are laid out, how multiple inheritance
is implemented, how virtual function calls are handled, and so on, so if
the name mangling were made the same, your programs would link against
libraries provided from other compilers but then crash when run.  For this
reason, the ARM @emph{encourages} compiler writers to make their name mangling
different from that of other compilers for the same platform.
Incompatible libraries are then detected at link time, rather than at run
time.

@node documentation, agreement with standards, problems linking with other libraries, User Problems
@section What documentation exists for g++ 2.x?

Almost none.  The gcc manual describes the C front end, and also the back
end, which is shared by the C++ compiler, but there is almost no
documentation for the C++ front end.  There is a Unix-style manual entry,
"g++.1", in the gcc-2.x distribution; this describes the extra
command-line options that g++ supports, and the #pragma interface and
#pragma implementation directives.

A draft of a document describing the g++ internals appears in the 2.3.3
distribution (called g++int.texi); it is still incomplete.

Work is proceeding on a user g++ document; with luck it will appear in the
next release.

@node agreement with standards, compiling standard libraries, documentation, User Problems
@section What are the differences between g++ and the ARM specification of C++?

The chief thing missing from g++ that is in the ARM is exceptions (the
other major compilers do not have exceptions either).  There are bits
and pieces of exception code present, but it is not presently usable.

The template implementation is still new.  The implementation in 2.3.3
represents a considerable improvement over that of previous releases,
however.  Still, it has many bugs.

g++ does not implement a separate pass to instantiate template functions
and classes at this point; for this reason, it will not work, for the most
part, to declare your template functions in one file and define them in
another.  The compiler will need to see the entire definition of the
function, and will generate a static copy of the function in each file
in which it is used.

As with any beta-test compiler, there are bugs.  You can help improve
the compiler by submitting detailed bug reports.

[A full bug list would be very long indeed, so I won't put one here.
I may add a list of frequently-reported bugs and "non-bugs" like the
static class members issue mentioned above].

@node compiling standard libraries, debugging on SVR4 systems, agreement with standards, User Problems
@section Will g++ compile InterViews?  The NIH class library?

The NIH class library uses a non-portable, compiler-dependent hack
to initialize itself, which makes life difficult for g++ users.
It will not work without modification, and I don't know what modifications
are required or whether anyone has done them successfully.

Brendan Kehoe of Cygnus Support is working on getting NIHCL to build with g++.
He says, "The NIHCL release will hopefully contain patches to gcc 2.3 to
let it build."

[ From Steinar Bang <steinarb@@idt.unit.no>]

InterViews 3.1 compiles and runs with gcc-2.3.3 and libg++-2.3, except
that the "doc" application immediately dumps core when you try to run it.
There is also a small glitch with idraw.

There is a patch for InterViews 3.1 from Johan Garpendahl
<garp@@isy.liu.se> available for FTP from site ``ugle.unit.no''.
It is in the file

/pub/X11/contrib/InterViews/g++/3.1-beta3-patch.

This fixes two things: the Doc coredump, and the pattern menu of idraw.
Read the instructions at the start of the file.

@node debugging on SVR4 systems,  , compiling standard libraries, User Problems
@section Debugging on SVR4 systems

``When I use the -g flag on C++ code on a System V Release 4 system,
I get lots of undefined symbols at link time.  Why?  Help!''

[From Ron Guilmette:]
The changes needed to get the g++ front-end to generate proper DWARF style
debugging information for System V Release 4 are not yet completed, nor
will they be until g++ version 2.4 (at the earliest).

There is nothing that you (as an end-user) can do to correct this problem.
(It is actually @emph{many} problems, and they are all very complex.)  Until
the g++ maintainers have time to fix this, you should simply @emph{avoid} using
the -g option when using g++ on SVR4.

@node legalities,  , User Problems, Top
@chapter What are the rules for shipping code built with g++ and libg++?

``Is it is possible to distribute programs for profit that are created
with g++ and use the g++ libraries?''

I am not a lawyer, and this is not legal advice.  In any case, I have
little interest in telling people how to violate the spirit of the
GNU licenses without violating the letter.  This section tells you
how to comply with the intention of the GNU licenses as best I understand
them.

The FSF has no objection to your making money.  Its only interest is that
source code to their programs, and libraries, and to modified versions of
their programs and libraries, is always available.

The short answer is that you do not need to release the source to
your program, but you can't just ship a stripped executable either.

Compiling your code with a GNU compiler does not affect its copyright;
it is still yours.  However, in order to ship code that links in a GNU
library such as libg++ there are certain rules you must follow.  The
rules are described in the file COPYING.LIB that accompanies gcc
distributions; it is also included in the libg++ distribution.
See that file for the exact rules.  The agreement is called the
Library GNU Public License or LGPL.  It is much "looser" than the
GNU Public License, or GPL, that covers must GNU programs.

Here's the deal: let's say that you use some version of libg++,
completely unchanged, in your software, and you want to ship only
a binary form of your code.  You can do this, but there are several
special requirements.  If you want to use libg++ but ship only object
code for your code, you have to ship source for libg++ (or ensure
somehow that your customer already has the source for the exact
version you are using), and ship your application in linkable form.
You cannot forbid your customer from reverse-engineering or extending
your program by exploiting its linkable form.

Furthermore, if you modify libg++ itself, you must provide source
for your modifications (making a derived class does not count as
modifying the library -- that is "a work that uses the library").

@page
@contents
@bye
--
Joe Buck    [e-mail]