
                      EGCS Frequently Asked Questions
                                      
   This FAQ tries to answer specific questions concerning EGCS. For
   general information regarding C resp. C++, please check the
   [1]comp.lang.c FAQ, [2]comp.lang.c++ FAQ, and the [3]comp.std.c++ FAQ.
     _________________________________________________________________
                                      
    1. [4]How is EGCS different from gcc2?
    2. [5]What is an open development model?
    3. [6]Releases and Forking
    4. [7]How to report bugs
    5. [8]`_IO_stdfile_0_lock' was not declared in this scope
    6. [9]Problems building the Fortran compiler
    7. [10]Problems building on MIPS platforms
    8. [11]Problems with exception handling on x86 platforms
    9. [12]Problems with code that works with other compilers or earlier
       gcc releases
          + [13]FD_ZERO macro
          + [14]Octave 2.0.13 does not compile
   10. [15]Problems with Invalid `asm' statements
   11. [16]Bootstrap comparison failures on HPs
   12. [17]Bootstrap loops rebuilding cc1 over and over
   13. [18]Dynamic linker is unable to find GCC libraries
   14. [19]libstdc++/libio tests fail badly with --enable-shared
   15. [20]Unable to run the testsuite
   16. [21]How to build a cross compiler
   17. [22]How to install both gcc2 and EGCS
   18. [23]Snapshots, how, when, why
   19. [24]Problems building Linux kernels
   20. [25]Virtual memory exhausted
   21. [26]GCC can not find GNU as/GNU ld
   22. [27]EGCS with Windows
   23. [28]EGCS with OS/2
   24. [29]cpp: Usage:... Error
   25. [30]Friend Templates
   26. [31]Where to find libg++
   27. [32]Why do I need autoconf, bison, xgettext, automake, etc 
   28. [33]Assembler error on AIX 4.3.0
   29. [34]Problems debugging EGCS code
   30. [35]Conflicts when using cvs update 
   31. [36]Using EGCS with GNAT/Ada
   32. [37]Using EGCS with GNU Pascal
   33. [38]Using CVS to download snapshots 
   34. [39]Why can't I build a shared library?
   35. [40]Linker core dumps on SunOS4
   36. [41]Assembler errors on Alpha targets
   37. [42]Signal 11 on Linux
   38. [43]Link failures using -bbigtoc on AIX 4.1
   39. [44]Dealing with spam on the lists
   40. [45]How do I pass flags like -fnew-abi to the testsuite?
   41. [46]Does EGCS support the O32 ABI on Irix?
   42. [47]Unable to bootstrap egcs-1.1 on AIX 4.3
   43. [48]Links to other FAQs for GCC on Irix platforms?
   44. [49]How to work around too long C++ symbol names? (-fsquangle)
   45. [50]How can I run the test suite with multiple options?
   46. [51]AIX 4.3 archive libraries ("not a COFF file")
   47. [52]Problems with egcs on NEXTSTEP 3.x systems
       
     _________________________________________________________________
                                      
How is EGCS different from gcc2?

   Six years ago, 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 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 want to make with EGCS.
   
   In brief, the three biggest differences between EGCS and gcc2 are:
     * More reexamination of basic architectural decisions of gcc and an
       interest in adding new optimizations;
     * working with the groups who have fractured out from gcc2 (like the
       Linux folks, the Intel optimizations folks, Fortran folks)
       including more front-ends; and finally
     * An open development model ([53]see below) for the development
       process.
       
   These three differences will work together to result in a more useful
   compiler, a more stable compiler, a central compiler that works for
   more people, a compiler that generates better code.
   
   There are a lot of exciting compiler optimizations that have come out.
   We want them in gcc. There are a lot of front ends out there for gcc
   for languages like Fortran or Pascal. We want them easily installable
   by users. After six years of working on gcc2, we've come to see
   problems and limitations in the way gcc is architected; it is time to
   address these again.
     _________________________________________________________________
                                      
What is an open development model?

   With EGCS, we are going to try a bazaar style[54][1] approach to its
   development: We're going to be making snapshots publicly available to
   anyone who wants to try them; we're going to 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: We're shooting for three by the end of 1997.
   
   In addition to weekly snapshots of the EGCS development sources, we
   are going to look at making the sources readable from a CVS server by
   anyone. We want to make it so external maintainers of parts of EGCS
   are able to commit changes to their part of EGCS directly into the
   sources without going through an intermediary.
   
   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.
   
   EGCS is not the first piece of software to use this open development
   process; FreeBSD, the Emacs lisp repository, and Linux are a few
   examples of the bazaar style of development.
   
   With EGCS, we will be adding new features and optimizations at a rate
   that has not been done since the creation of gcc2; these additions
   will 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 ``[55]The Cathedral and the Bazaar''. The paper is a useful
     starting point for discussions.
     
     _________________________________________________________________
                                      
Releases and Forking?

   Some folks have questioned whether or not making releases is
   consistent with the goals of the EGCS project and whether or not
   making releases is a fork from gcc2.

The EGCS project has several goals, including:

  * Experimenting with a new development model, release process and
  release packaging,

  * Using the new development model to accelerate development of new
  features, optimizations, etc for future inclusion in gcc,

  * Providing high quality releases to the public.

An EGCS release is a copy of the EGCS sources that the developers have
tested and are believed to be suitable for wider scale use and testing.

Making releases of stable, tested sources is both a goal and a means by
which we hope to achieve other goals of the EGCS project.

The existence of a stable tested release allows EGCS to be more thoroughly
used and tested by a wider audience than is capable of testing snapshots.
The expanded audience provides developers with critical feedback in a
timely manner, which is beneficial to GCC as a whole and is consistent with
the stated goals of EGCS.

The gcc maintainers are encouraged to migrate tested fixes and new features
from EGCS into gcc at their discretion.  EGCS maintainers are willing to
assist the gcc maintainers as time permits.  EGCS periodically merges in
changes from gcc into the EGCS sources.

What will keep EGCS from becoming a fork is cooperation between the
developers of gcc and EGCS.

We don't see this situation as significantly different than other projects
that make releases based on some version of the gcc sources (Cygnus, g77,
etc).  All the code is still available for inclusion in gcc at the discretion
of the gcc maintainers.

     _________________________________________________________________
                                      
How to report bugs

   There are complete instructions in the egcs info manual, section Bugs.
   The manual can be read using `M-x info' in Emacs, or if the GNU info
   program is installed on your system by `info --node "(gcc)Bugs"'. Or
   see the file [56]BUGS included with the egcs source code.
   
   Before you report a bug for the C++ compiler, you might check the
   [57]list of well-known bugs.
   
   In short, if egcs says Internal compiler error (or any other error
   that you'd like us to be able to reproduce, for that matter), please
   mail a bug report to [58]egcs-bugs@cygnus.com including:
     * The egcs version
     * The system type
     * All options you passed to egcs
     * Preprocessed output of the source file that caused the compiler
       error
       
   All this can normally be accomplished by mailing the command line, the
   output of the command, and the resulting `your-file.i' for C, or
   `your-file.ii' for C++, corresponding to:
   
   egcs -v --save-temps all-your-options your-file.c
   
   Typically the CPP output will be large, so please compress the
   resulting file with one of the popular compression programs such as
   gzip, bzip2, compress or pkzip, then include the compressed CPP output
   as an attachment to your message.
   
   The egcs lists have message size limits (40 kbytes) and uncompressed
   bug reports over those limits will be bounced. Most compressed but
   reports are allowed to exceed the limits unless they are unreasonably
   huge.
     _________________________________________________________________
                                      
`_IO_stdfile_0_lock' was not declared in this scope

   If you get this error, it means either EGCS incorrectly guessed what
   version of libc is installed on your Linux system, or you incorrectly
   specified a version of glibc when configuring EGCS.
   
   If you did not provide a target name when configuring EGCS, then
   you've found a bug which needs to be reported. If you did provide a
   target name at configure time, then you should reconfigure without
   specifying a target name.
     _________________________________________________________________
                                      
Problems building the Fortran compiler

   The Fortran front end can not be built with most vendor compilers; it
   must be built with gcc. As a result, you may get an error if you do
   not follow the install instructions carefully.
   
   In particular, instead of using "make" to build EGCS, you should use
   "make bootstrap" if you are building a native compiler or "make cross"
   if you are building a cross compiler.
   
   It has also been reported that the Fortran compiler can not be built
   on Red Hat 4.X Linux for the Alpha. Fixing this may require upgrading
   binutils or to Red Hat 5.0; we'll provide more information as it
   becomes available.
     _________________________________________________________________
                                      
Problems building on MIPS platforms

   EGCS requires the use of GAS on all versions of Irix, except Irix 6,
   due to limitations in older Irix assemblers.
   
   Either of these messages indicates that you are using the MIPS
   assembler when instead you should be using GAS.

    as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
          .4byte $LECIE1-$LSCIE1
    as0: Error: ./libgcc2.c, line 1:malformed statement

     _________________________________________________________________
                                      
    as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol i
n expression
    .word $LECIE1-$LSCIE1

   For Irix 6, you should use the native assembler as GAS is not yet
   supported on this platform.
     _________________________________________________________________
                                      
Problems with exception handling on x86 platforms

   If you are using the GNU assembler (aka gas) on an x86 platform and
   exception handling is not working correctly, then odds are you're
   using a buggy assembler.
   
   We recommend binutils-2.8.1.0.15 or newer.
   [59]binutils-2.8.1.0.23 source
   [60]binutils-2.8.1.0.23 x86 binary for libc5
   [61]binutils-2.8.1.0.23 x86 binary for glibc2 Or, you can try a
   [62]binutils snapshot; however, be aware that the binutils snapshot is
   untested and may not work (or even build). Use it at your own risk.
     _________________________________________________________________
                                      
Problems with code that works with other compilers or earlier gcc releases

   Unfortunately, improvements in tools that are widely used are sooner
   or later bound to break something. Sometimes, the code that breaks was
   wrong, and then that code should be fixed, even if it works for
   earlier versions of gcc or other compilers. The following problems
   with some releases of widely used packages have been identified:
     * FD_ZERO macro
       The FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses
       [63]invalid asm clobbers. The following rewrite by Ulrich Drepper
       <drepper@cygnus.com> should fix this:

  # define __FD_ZERO(fdsetp) \
    do { \
      int __d0, __d1; \
    __asm__ __volatile__ ("cld; rep; stosl" \
                          : "=m" (((__fd_mask *) \
                                   (fdsetp))[__FDELT (__FD_SETSIZE)]), \
                            "=&c" (__d0), "=&D" (__d1) \
                          : "a" (0), "1" (sizeof (__fd_set) \
                                          / sizeof (__fd_mask)), \
                            "2" ((__fd_mask *) (fdsetp)) \
                          : "memory"); \
    } while (0)
     * Octave 2.0.13 does not compile
       
   Apparently Octave 2.0.13 uses some C++ features which have been
   obsoleted and thus fails to build with egcs-1.1 and later. This
   [64]patch to Octave should fix this.
     _________________________________________________________________
                                      
Problems with invalid `asm' statements

   Previous releases of gcc (for example, gcc-2.7.2.X) did not detect as
   invalid a clobber specifier that clobbered an operand. Instead, it
   could spuriously and silently generate incorrect code for certain
   non-obvious cases of source code. Even more unfortunately, the manual
   (Using and Porting GCC, section Extended Asm, see the [65]bug report
   entry) did not explicitly say that it was invalid to specify clobber
   registers that were destined to overlap operands; it could arguably be
   interpreted that it was correct to clobber an input operand to mark it
   as not holding a usable value after the asm.
   
   For the general case, there is no way to tell whether a specified
   clobber is intended to overlap with a specific (input) operand or is a
   program error, where the choice of actual register for operands failed
   to avoid the clobbered register. Such unavoidable overlap is detected
   by versions egcs-2.92.18 19981104 and above, and flagged as an error
   rather than accepted. An error message is given, such as:

foo.c: In function `foo':
foo.c:7: Invalid `asm' statement:
foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG.

   Unfortunately, a lot of existing software, for example the [66]Linux
   kernel version 2.0.35 for the Intel x86, has constructs where input
   operands are marked as clobbered.
   
   The manual now describes how to write constructs with operands that
   are modified by the construct, but not actually used. To write an asm
   which modifies an input operand but does not output anything usable,
   specify that operand as an output operand outputting to an unused
   dummy variable.
   
   In the following example for the x86 architecture (taken from the
   Linux 2.0.35 kernel -- include/asm-i386/delay.h), the register-class
   constraint "a" denotes a register class containing the single register
   "ax" (aka. "eax"). It is therefore invalid to clobber "ax"; this
   operand has to be specified as an output as well as an input. The
   following code is therefore invalid:

extern __inline__ void
__delay (int loops)
{
  __asm__ __volatile__
    (".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
     : /* no outputs */
     : "a" (loops)
     : "ax");
}

   It could be argued that since the register class for "a" contains only
   a single register, this could be detected as an "obvious" intended
   clobber of the input operand. While that is feasible, it opens up for
   further "obvious" cases, where the level of obviousness changes from
   person to person. As there is a correct way to write such asm
   constructs, this obviousness-detection is not needed other than for
   reasons of compatibility with an existing code-base, and that code
   base can be corrected.
   
   This corrected and clobber-less version, is valid for egcs of current
   CVS, as well as for previous versions of gcc:

extern __inline__ void
__delay (int loops)
{
  int dummy;

  __asm__ __volatile__
    (".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
     : "=a" (dummy)
     : "0" (loops));
}

   Note that the asm construct now has an output operand, but it is
   unused. Normally asm constructs with only unused output operands may
   be removed by gcc, unless marked volatile as above.
     _________________________________________________________________
                                      
Bootstrap comparison failures on HPs

   If you bootstrap the compiler on hpux10 using the HP assembler instead
   of gas, every file will fail the comparison test.
   
   The HP assembler inserts timestamps into object files it creates,
   causing every file to be different. The location of the timestamp
   varies for each object file, so there's no real way to work around
   this mis-feature.
   
   Odds are your compiler is fine, but there's no way to be certain.
   
   If you use GAS on HPs, then you will not run into this problem because
   GAS never inserts timestamps into object files. For this and various
   other reasons we highly recommend using GAS on HPs.
     _________________________________________________________________
                                      
Bootstrap loops rebuilding cc1 over and over

   When building EGCS, the build process loops rebuilding cc1 over and
   over again. This happens on mips-sgi-irix5.2, and possibly other
   platforms.
   
   It has been reported that this is a known bug in the make shipped with
   Irix 5.2. We recommend you use GNU make instead of the vendor supplied
   make program; however, you may have success with "smake" on Irix 5.2
   if you do not have GNU make available.
     _________________________________________________________________
                                      
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 EGCS.
   
   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.
     _________________________________________________________________
                                      
Unable to run the testsuite

   If you get a message about unable to find "standard.exp" when trying
   to run the EGCS testsuites, then your dejagnu is too old to run the
   EGCS tests. You will need to get a newer version of dejagnu; we've
   made a [67]dejagnu snapshot available until a new version of dejagnu
   can be released.
     _________________________________________________________________
                                      
How to build a cross compiler

   Building cross compilers is a rather complex undertaking because they
   usually need additional software (cross assembler, cross linker,
   target libraries, target include files, etc).
   
   We recommend reading the [68]crossgcc FAQ for information about
   building cross compilers.
   
   If you have all the pieces available, then `make cross' should build a
   cross compiler. `make LANGUAGES="c c++" install' will install the
   cross compiler.
   
   Note that if you're trying to build a cross compiler in a tree which
   includes binutils-2.8 in addition to EGCS, then you're going to need
   to make a couple minor tweaks so that the cross assembler, linker and
   nm utilities will be found.
   
   binutils-2.8 builds those files as gas.new, ld.new and nm.new; EGCS
   gcc looks for them using gas-new, ld-new and nm-new, so you may have
   to arrange for any symlinks which point to <file>.new to be changed to
   <file>-new.
     _________________________________________________________________
                                      
Snapshots, how, when, why

   We make snapshots of the EGCS sources about once a week; there is no
   predetermined schedule. These snapshots are intended to give everyone
   access to work in progress. Any given snapshot may generate incorrect
   code or even fail to build.
   
   If you plan on downloading and using snapshots, we highly recommend
   you subscribe to the EGCS mailing lists. See [69]mailing lists on the
   main EGCS page for instructions on how to subscribe.
   
   When using the diff files to update from older snapshots to newer
   snapshots, make sure to use "-E" and "-p" arguments to patch so that
   empty files are deleted and full pathnames are provided to patch. If
   your version of patch does not support "-E", you'll need to get a
   newer version. Also note that you may need autoconf, autoheader and
   various other programs if you use diff files to update from one
   snapshot to the next.
     _________________________________________________________________
                                      
How to install both EGCS and gcc2

   It may be desirable to install both EGCS and gcc2 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 EGCS compiler and available in /usr/local/bin; also assume
   that you want "gcc2" to be the gcc2 compiler and also available in
   /usr/local/bin.
   
   The easiest way to do this is to configure EGCS with
   --prefix=/usr/local/egcs and gcc2 with --prefix=/usr/local/gcc2. Build
   and install both compilers. Then make a symlink from
   /usr/local/bin/gcc to /usr/local/egcs/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.
     _________________________________________________________________
                                      
Problems building Linux kernels

   If you have tried to build a 2.0.xx kernel for Intel machines with
   EGCS, then you are on your own. The 2.0.xx kernels are to be built
   only with gcc-2.7.2. They use certain asm constructs which are
   incorrect, but (by accident) happen to work with gcc-2.7.2. If you
   insist on building 2.0.xx kernels with egcs, you may be interested in
   this [70]patch which fixes some of the asm problems. You will also
   want to change asm constructs to [71]avoid clobbering their input
   operands.
   
   If you installed a recent binutils/gas snapshot on your Linux system,
   you may not be able to build the kernel because objdump does not
   understand the "-k" switch. The solution for this problem is to remove
   /usr/bin/encaps.
   
   The reason you must remove /usr/bin/encaps is because it is an
   obsolete program that was part of older binutils distributions; the
   Linux kernel's Makefile looks for this program to decide if you have
   an old or a new binutils. Problems occur if you installed a new
   binutils but haven't removed encaps, because the Makefile thinks you
   have the old one. So zap it; trust us, you won't miss it.
   
   You may get an internal compiler error compiling process.c in newer
   versions of the Linux kernel on x86 machines. This is a bug in an asm
   statement in process.c, not a bug in EGCS. XXX How to fix?!?
   
   You may get errors with the X driver of the form
_X11TransSocketUNIXConnect: Can't connect: errno = 111

   It's a kernel bug. The function sys_iopl in arch/i386/kernel/ioport.c
   does an illegal hack which used to work but is now broken since GCC
   optimizes more aggressively . The newer 2.1.x kernels already have a
   fix which should also work in 2.0.32.
     _________________________________________________________________
                                      
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.
     _________________________________________________________________
                                      
GCC can not find GNU as/GNU ld

   To ensure that EGCS finds the GNU assembler (the GNU loader), which
   are required by [72]some configurations, you should configure these
   with the same --prefix option as you used for EGCS. Then build &
   install GNU as (GNU ld) and proceed with building EGCS.
   
   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.
   
   Post-1.1 snapshots of egcs allow 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'. EGCS 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.
     _________________________________________________________________
                                      
EGCS with Windows

   EGCS does not currently support windows, either natively or with the
   cygwin32 dll. However Mumit Khan has been working on supporting
   Windows with EGCS. You should check out his site if you're interested
   in Windows support. [73]GNU Win32 related projects
     _________________________________________________________________
                                      
EGCS with OS/2

   EGCS does not currently support OS/2. However, Andrew Zabolotny has
   been working on a generic os/2 port with pgcc. The current code code
   can be found at [74]http://www.goof.com/pcg/os2.
     _________________________________________________________________
                                      
cpp: Usage:... Error

   If you get an error like this when building EGCS (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.
     _________________________________________________________________
                                      
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.
     _________________________________________________________________
                                      
Where to find libg++

   Many folks have been asking where to find libg++ for EGCS. First we
   should point out that few programs actually need libg++; most only
   need libstdc++/libio which are included in the EGCS distribution.
   
   If you do need libg++ you can get a libg++ release that works with
   EGCS from
   [75]ftp://egcs.cygnus.com/pub/egcs/infrastructure/libg++-2.8.1.2.tar.g
   z or [76]ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1.2.tar.gz.
   Note that the 2.8.2 snapshot pre-dates the 2.8.1.2 release.
     _________________________________________________________________
                                      
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 EGCS.
   
   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.

touch `find egcs -name configure -print`
touch `find egcs/texinfo -name Makefile.in -print`
touch `find egcs/texinfo -name \*.pot -print`
touch `find egcs/texinfo -name \*.gmo -print`
touch egcs/gcc/{c-parse.y,cstamp-h.in,c-gperf.h,c-parse.c,c-parse.h,cexp.c}
touch egcs/gcc/cp/parse.{c,h}
touch egcs/gcc/java/{parse.c,parse.h,parse-scan.c}
touch egcs/gcc/objc/objc-parse.{c,y}
touch egcs/libf2c/libU77/config.hin
touch egcs/libf2c/libU77/stamp-h.in
touch egcs/contrib/fixinc/{fixincl.x,inclhack.sh,fixincl.sh}
touch egcs/gcc/fixinc/{fixincl.x,inclhack.sh,fixincl.sh}

   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 egcs.
   
   Autoconf is available from [77]http://sourceware.cygnus.com/autoconf/;
   have a look at ftp://egcs.cygnus.com/pub/egcs/infrastructure/ for the
   other packages.
   
     _________________________________________________________________
                                      
Assembler error on AIX 4.3.0

   The initial assembler shipped with AIX 4.3.0 generates incorrect
   object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUPUT FROM
   COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer
   Support and from its [78]service.boulder.ibm.com website as PTF
   U453956. This fix is incorporated in AIX 4.3.1 and above.
     _________________________________________________________________
                                      
Problems debugging EGCS code

   On some systems EGCS will produce dwarf debug records by default;
   however the current gdb-4.16 release may not be able to read such
   debug records.
   
   You can either use the argument "-gstabs" instead of "-g" or pick up
   the current beta copy of gdb-4.17 to work around the problem.
     _________________________________________________________________
                                      
Conflicts when using cvs update

   It is not uncommon to get CVS conflict messages for some generated
   files when updating your local sources from the CVS repository.
   Typically such conflicts occur with bison or autoconf generated files.
   
   As long as you haven't been making modifications to the generated
   files or the generator files, it is safe to delete the offending file,
   then run cvs update again to get a new copy.
     _________________________________________________________________
                                      
Using EGCS with GNAT/Ada

   The GNU Ada front-end is not currently supported by EGCS; however, it
   is possible to build the GNAT compiler with a little work.
   
   First, retrieve the gnat-3.10p sources. The sources for the Ada front
   end and runtime all live in the "ada" subdirectory. Move that
   subdirectory to egcs/gcc/ada.
   
   Second, apply the patch found in egcs/gcc/README.gnat.
   
   Finally, rebuild per the GNAT build instructions.
     _________________________________________________________________
                                      
Using EGCS with GNU Pascal

   The [79]GNU Pascal front-end does work with egcs-1.1 It does not work
   with egcs-1.0.x and the main branch as of egcs-2.92.18. A tarball can
   be found at [80]ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/.
     _________________________________________________________________
                                      
Using CVS to download snapshots

   It is possible to checkout specific snapshots with CVS or to check out
   the latest snapshot.
   
   We use CVS tags to identify each snapshot we make. Snapshot tags have
   the form "egcs_ss_YYYYMMDD". In addition, the latest official snapshot
   always has the tag "egcs_latest_snapshot".
     _________________________________________________________________
                                      
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

     _________________________________________________________________
                                      
SunOS4 Linker core dumps

   A bug in the SunOS4 linker will cause it to crash when linking -fPIC
   compiled objects.
   
   To fix this problem you can either use the most recent version of
   binutils or get the latest SunOS4 linker patch (patch ID 100170-10)
   from Sun's patch site.
     _________________________________________________________________
                                      
Assembler errors on Alpha targets

   Error: Unknown pseudo-op: `.arch'
   Linux/Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may see
   errors of this sort. This is a signal that a new assembler is needed
   if you want to generate BWX insns for your machine.
   
   The version shipped with Red Hat 4.2 (2.7.0.2) has a fault wherein it
   will silently generate incorrect code. The version shipped with Red
   Hat 5.0 (2.8.0.1) is not broken, but required an extra -m21164a
   argument on the command-line. In order to visibly trap 2.7.0.2, I now
   issue DEC's .arch pseudo into the assembly. Relieving the problem of
   mucking with command-line arguments for 2.8.0.1 is a pleasant side
   effect.
   
   If you've got Red Hat 5.0 installed, you may grab binutils 2.9.1 and
   be happy. If you've got Red Hat 4.2, bugs make it much harder to
   upgrade pieces on your own, and you are better off upgrading the
   entire system.
   
   In either case, your problem may be bypassed by not emitting BWX code
   by default. Do this by using

        configure alphaev5-unknown-linux-gnulibc1

   if you have RH 4.2, or
        configure alphaev5-unknown-linux-gnu

   if you have RH 5.0.
   
   Error: macro requires $at register while noat in effect
   This error also indicates that you should upgrade to a newer version
   of the assembler, 2.9 or later. If you can not upgrade the assembler,
   the compiler option "-Wa,-m21164a" may work around this problem.
     _________________________________________________________________
                                      
Signal 11 on Linux

   If you receive Signal 11 errors when building on Linux, then it is
   possible you have a hardware problem. Further information on this can
   be found on [81]www.bitwizard.nl.
     _________________________________________________________________
                                      
Link failures using -bbigtoc on AIX 4.1

   Some versions of the AIX binder (linker) can fail with a relocation
   overflow severe error when the -bbigtoc option is used to link
   GCC-produced object files into an executable that overflows the TOC. A
   fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND
   -BBIGTOC) is available from IBM Customer Support and from its
   [82]service.boulder.ibm.com website as PTF U455193.
     _________________________________________________________________
                                      
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++

     _________________________________________________________________
                                      
Does EGCS support the O32 ABI on Irix

   Gcc does not correctly pass/return structures which are smaller than
   16 bytes and which are not 8 bytes. The problem is very involved and
   difficult to fix. It affects a number of other targets also, but irix6
   is affected the most, because it is a 64 bit target, and 4 byte
   structures are common. The exact problem is that structures are being
   padded at the wrong end, e.g. a 4 byte structure is loaded into the
   lower 4 bytes of the register when it should be loaded into the upper
   4 bytes of the register.
   
   Gcc is consistent with itself, but not consistent with the SGI C
   compiler [and the SGI supplied runtime libraries], so the only
   failures that can happen are when there are library functions that
   take/return such structures. There are very few such library
   functions. I can only recall seeing two of them: inet_dtoa, and
   semctl.
   
   A possible workaround: if you have a program that calls inet_dtoa or
   semctl, you may compile it with gcc -mabi=64
     _________________________________________________________________
                                      
Unable to bootstrap egcs-1.1 on AIX 4.3

   The complete egcs-1.1 distribution will try to build 64-bit versions
   of all runtime libraries which will fail for libstdc++. If only a C
   compiler is desired, configure and build egcs-core-1.1. If other
   languages are needed, configure as if the system were
   rs6000-ibm-aix4.2, which will disable 64-bit support. This will be
   fixed in the egcs-1.1.1 release.
     _________________________________________________________________
                                      
Links to other FAQs for GCC on Irix platforms

   [83]http://reality.sgi.com/ariel/freeware
     _________________________________________________________________
                                      
How to work around too long C++ symbol names? (-fsquangle)

   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
   egcs, 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 egcs and any C++ libraries.
     _________________________________________________________________
                                      
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.
     _________________________________________________________________
                                      
AIX 4.3 archive libraries ("not a COFF file")

   AIX 4.3 utilizes a new "large format" archive to support both 32-bit
   and 64-bit object modules. The routines provided in AIX 4.3.0 and AIX
   4.3.1 to parse archive libraries did not handle the new format
   correctly. These routines are used by GCC and result in error messages
   during linking such as "not a COFF file". The version of the routines
   shipped with AIX 4.3.1 should work for a 32-bit environment. The -g
   option of the archive command may be used to create archives of 32-bit
   objects using the original "small format". A correct version of the
   routines is shipped with AIX 4.3.2.
     _________________________________________________________________
                                      
Problems with EGCS on NEXTSTEP 3.x systems

   On NEXTSTEP 3.x where x < 3 the build of egcs will abort during stage1
   with an error message like this:

_eh
/usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section
/usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character
valued 95 (_).

   The reason for this is the fact that NeXT's assembler for these
   versions of the operating system does not support the .section pseudo
   op that's needed for full C++ exception functionality. As NeXT's
   assembler is a derived work from GNU as, a free replacement that does
   can be obtained at
   [84]ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s
   .tar.gz.
     _________________________________________________________________
                                      
   [85]Return to the EGCS home page
   
   Last modified: December 2, 1998

References

   1. http://www.eskimo.com/~scs/C-faq/top.html
   2. http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/
   3. http://reality.sgi.com/employees/austern_mti/std-cfaq.html
   4. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#gcc-2-diff
   5. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#open-development
   6. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#release-fork
   7. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#bugreport
   8. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#morelibc
   9. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#fortran
  10. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#mips
  11. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#x86eh
  12. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#broken
  13. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#fdzero
  14. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#octave
  15. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#asmclobber
  16. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#hpcompare
  17. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#makebugs
  18. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#rpath
  19. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#rpath
  20. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#dejagnu
  21. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#cross
  22. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#multiple
  23. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#snapshot
  24. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#linuxkernel
  25. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#memexhausted
  26. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#gas
  27. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#windows
  28. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#os2
  29. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#environ
  30. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#friend
  31. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#libg++
  32. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#generated_files
  33. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#aixas
  34. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#gdb
  35. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#conflicts
  36. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#gnat
  37. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#gpc
  38. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#cvssnapshots
  39. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#picflag-needed
  40. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#sunos4ld
  41. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#axparch
  42. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#sig11
  43. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#bigtoc
  44. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/spam.html
  45. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#testoptions
  46. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#o32abi
  47. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#aix43
  48. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#irixlinks
  49. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#squangle
  50. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#multipletests
  51. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#aixcoff
  52. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#next
  53. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#open-development
  54. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#cathedral-vs-bazaar
  55. http://locke.ccil.org/~esr/writings/cathedral.html
  56. file://localhost/cgi-bin/cvsweb/gcc/BUGS?rev=1.1
  57. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/c++bugs.html
  58. mailto:egcs-bugs@cygnus.com
  59. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.23.tar.gz
  60. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.23.bin.tar.gz
  61. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.23.glibc.bin.tar.gz
  62. ftp://egcs.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz
  63. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#asmclobber
  64. http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/270
  65. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#bugreport
  66. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#linuxkernel
  67. ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-980528.tar.gz
  68. ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ
  69. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/index.html#mailinglists
  70. http://www.suse.de/~florian/kernel+egcs.html
  71. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/faq.html#asmclobber
  72. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/install/specific.html
  73. http://www.xraylith.wisc.edu/~khan/software/gnu-win32
  74. http://www.goof.com/pcg/os2
  75. ftp://egcs.cygnus.com/pub/egcs/infrastructure/libg++-2.8.1.2.tar.gz
  76. ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1.2.tar.gz
  77. http://sourceware.cygnus.com/autoconf/
  78. http://service.boulder.ibm.com/
  79. http://home.pages.de/~GNU-Pascal/
  80. ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/
  81. http://www.bitwizard.nl/sig11/
  82. http://service.boulder.ibm.com/
  83. http://reality.sgi.com/ariel/freeware/
  84. ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz
  85. file://localhost/egcs/carton/law/trash/egcs-1.1.1/INSTALL/index.html
