
                      egcs Frequently Asked Questions
                                      
    1. [1]How is egcs different from gcc2?
    2. [2]What is an open development model?
    3. [3]Releases and Forking
    4. [4]bits/libc-lock.h: No such file or directory
    5. [5]`_IO_stdfile_0_lock' was not declared in this scope
    6. [6]Problems building the Fortran compiler
    7. [7]Problems building on MIPS platforms
    8. [8]Problems with exception handling on x86 platforms
    9. [9]Bootstrap comparison failures on HPs
   10. [10]Bootstrap loops rebuilding cc1 over and over
   11. [11]Dynamic linker is unable to find GCC libraries
   12. [12]libstdc++/libio tests fail badly with --enable-shared
   13. [13]Unable to run the testsuite
   14. [14]How to build a cross compiler
   15. [15]How to install both gcc2 and egcs
   16. [16]Snapshots, how, when, why
   17. [17]Problems building Linux kernels
   18. [18]Virtual memory exhausted
   19. [19]GCC can not find GAS
   20. [20]egcs does not work on Red Hat 5.0
   21. [21]Unable to bootstrap on x86 Solaris2.{5,6}
   22. [22]EGCS with Windows
   23. [23]EGCS with OS/2
   24. [24]cpp: Usage:... Error
   25. [25]EGCS will not build KDE
   26. [26]Friend Templates
   27. [27]Where to find libg++
   28. [28]Why do I need autoconf & bison
   29. [29]EGCS does not work on AIX 4.3
   30. [30]Problems debugging egcs code
   31. [31]Conflicts when using cvs update 
       
     _________________________________________________________________
                                      
How is egcs be 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 rexamination of basic architectual 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 ([32]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[33][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 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 intergrated--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 ``[34]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.

     _________________________________________________________________
                                      
bits/libc-lock.h: No such file or directory

   This entry should be obsolete, egcs should handle these beta versions
   of glibc2 correctly.
   
   egcs includes a tightly integrated libio and libstdc++ implementation
   which can cause problems on hosts which have libio integrated into
   their C library (most notably Linux).
   
   We believe that we've solved the major technical problems for the most
   common versions of libc found on Linux systems. However, some versions
   of Linux use pre-release versions of glibc2, which egcs has trouble
   detecting and correctly handling.
   
   If you're using one of these pre-release versions of glibc2, you may
   get a message "bits/libc-lock.h: No such file or directory" when
   building egcs. Unfortunately, to fix this problem you will need to
   update your C library to glibc2.0.5c.
     _________________________________________________________________
                                      
`_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
   supported on Irix 6.
     _________________________________________________________________
                                      
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.
   [35]binutils-2.8.1.0.20 source
   [36]binutils-2.8.1.0.20 x86 binary for libc5
   [37]binutils-2.8.1.0.20 x86 binary for glibc2 Or, you can try a
   [38]binutils snapshot; however, be aware that the binutils snapshot is
   untested and may not work (or even build). Use it at your own risk.
     _________________________________________________________________
                                      
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 asembler 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.
   
   This is probably a bug somewhere in the egcs Makefile. Until we find
   and fix this bug we recommend you use GNU make instead of vendor
   supplied make programs.
     _________________________________________________________________
                                      
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 explaination 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 [39]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 [40]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 &ltfile>.new to be changed
   to &ltfile>-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 [41]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 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 GAS

   Some configurations like irix4, irix5, hpux* require the use of the
   GNU assembler intead of the system assembler. To ensure that egcs
   finds the GNU assembler, you should configure the GNU assembler with
   the same --prefix option as you used for egcs. Then build & install
   the GNU assembler. After the GNU assembler has been installed, proceed
   with building egcs.
     _________________________________________________________________
                                      
egcs does not work on Red Hat 5.0

   This entry is obsolete with the release of egcs-1.0.1 which should
   handle Red Hat 5.0 correctly.
   
   egcs-1.0 does not currently work with Red Hat 5.0 on some platforms;
   we'll update this entry with more information as it becomes available.
   
   You may want to try this [42]proposed patch for Red Hat 5.0. Please
   let us know if you use this patch and whether or not it works.
     _________________________________________________________________
                                      
Unable to bootstrap on x86 Solaris 2.{5,6}

   This entry is obsolete with the release of egcs-1.0.1 which should
   handle x86 Solaris systems correctly.
   
   This patch should fix the problem
Index: t-sol2
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/t-sol2,v
retrieving revision 1.2
diff -c -3 -p -r1.2 t-sol2
*** t-sol2      1997/09/04 23:54:04     1.2
--- t-sol2      1997/12/04 07:19:07
*************** crtn.o: $(srcdir)/config/i386/sol2-cn.as
*** 31,36 ****
  # to produce a shared library, but since we don't know ahead of time when
  # we will be doing that, we just always use -fPIC when compiling the
  # routines in crtstuff.c.

! CRTSTUFF_T_CFLAGS = -fPIC
  TARGET_LIBGCC2_CFLAGS = -fPIC
--- 31,40 ----
  # to produce a shared library, but since we don't know ahead of time when
  # we will be doing that, we just always use -fPIC when compiling the
  # routines in crtstuff.c.
+ #
+ # We must also enable optimization to avoid having any code appear after
+ # the call & alignment statement, but before we switch back to the
+ # .text section.

! CRTSTUFF_T_CFLAGS = -fPIC -O2
  TARGET_LIBGCC2_CFLAGS = -fPIC

     _________________________________________________________________
                                      
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. [43]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 [44]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.
     _________________________________________________________________
                                      
EGCS will not build KDE

   Previous versions of g++ accepted (as a GNU extension)
   constructor-arguments for the objects in an array of objects
   dynamically allocated with new. Here's an example of this construct:

    struct S { S(int); }
    void f() { new S[3](6); }

   However, this construct is not allowed by the ANSI/ISO Standard, and
   is no longer accepted by g++.
   
   KDE uses such constructs and therefore will not build with egcs; note
   patches are available to fix KDE.
     _________________________________________________________________
                                      
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. An error in the last public comment
draft of the ANSI/ISO C++ Standard has led people to believe that was not
necessary, but it is, and it was fixed in the final version of the Standard.
  __________________________________________________________________________
                                       
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++ snapshot which works with egcs from
[45]ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980119.tar.gz
  __________________________________________________________________________
                                       
Why do I need autoconf/bison

If you're using diffs up dated from one snapshot to the next, or if you're
using the CVS repository, you may need autoconf, bison, or possibly other tools
to rebuild egcs.

This is necessary because neither diff nor cvs keep timestamps correct. So it
is possible for "make" to think a generated file is out of date.

If you do not have autoconf, bison, etc, then you can issue the following
commands to touch all the generated files.


touch `find egcs -name configure -print`
touch egcs/gcc/c-parse.y
touch egcs/gcc/objc/objc-parse.y
touch egcs/gcc/{cstamp-h.in,c-gperf.h,c-parse.c,c-parse.h,cexp.c}
touch egcs/gcc/cp/{parse.c,parse.h}
touch egcs/gcc/objc/objc-parse.c

  __________________________________________________________________________
                                       
EGCS does not work on AIX 4.3

EGCS does not currently support AIX4.3; however, if you want to try and make it
work with AIX 4.3 we highly recommend you get the fix for APAR IX74254 (64BIT
DISASSEMBLED OUPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) which is available
from IBM Customer Support and IBM's service.boulder.ibm.com website.
  __________________________________________________________________________
                                       
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.
  __________________________________________________________________________
                                       
[46]Return to the egcs home page

Last modified: March 04, 1998

References

   1. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#gcc-2-diff
   2. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#open-development
   3. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#release-fork
   4. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#libc-lock
   5. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#morelibc
   6. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#fortran
   7. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#mips
   8. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#x86eh
   9. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#hpcompare
  10. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#makebugs
  11. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#rpath
  12. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#rpath
  13. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#dejagnu
  14. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#cross
  15. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#multiple
  16. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#snapshot
  17. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#linuxkernel
  18. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#memexhausted
  19. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#gas
  20. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#rh5.0
  21. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#x86solaris
  22. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#windows
  23. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#os2
  24. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#environ
  25. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#kde
  26. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#friend
  27. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#libg++
  28. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#autoconf/bison++
  29. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#aix
  30. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#gdb
  31. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#conflicts
  32. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#open-development
  33. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/faq.html#cathedral-vs-bazaar
  34. http://locke.ccil.org/~esr/writings/cathedral.html
  35. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.20.tar.gz
  36. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.20.bin.tar.gz
  37. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.20.glibc.bin.tar.gz
  38. ftp://egcs.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz
  39. ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz
  40. ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1
  41. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/index.html#mailinglists
  42. http://www.cygnus.com/ml/egcs/1997-Dec/0594.html
  43. http://www.xraylith.wisc.edu/~khan/software/gnu-win32
  44. http://www.goof.com/pcg/os2
  45. ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980119.tar.gz
  46. file://localhost/.automount/hurl/root/puke/law/egcs-1.0.1/INSTALL/index.html