path: root/INSTALL/FAQ

                      egcs Frequently Asked Questions
                                      
    1. [1]How is egcs be 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]cpp: Usage:... Error
     [24]EGCS will not build KDE 
         _____________________________________________________________
                                        
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
       these:
          + 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 ([25]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[26][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 ``[27]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.
       [28]binutils-2.8.1.0.15 source
       [29]binutils-2.8.1.0.15 x86 binary for libc5
       [30]binutils-2.8.1.0.15 x86 binary for glibc2 Or, you can try a
       [31]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 [32]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 [33]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 [34]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 [35]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. [36]GNU Win32 related
       projects
         _____________________________________________________________
                                        
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.
         _____________________________________________________________
                                        
       [37]Return to the egcs home page
       Last modified: Jan 2, 1998

References

   1. file://localhost/home/law/INSTALL/faq.html#gcc-2-diff
   2. file://localhost/home/law/INSTALL/faq.html#open-development
   3. file://localhost/home/law/INSTALL/faq.html#release-fork
   4. file://localhost/home/law/INSTALL/faq.html#libc-lock
   5. file://localhost/home/law/INSTALL/faq.html#morelibc
   6. file://localhost/home/law/INSTALL/faq.html#fortran
   7. file://localhost/home/law/INSTALL/faq.html#mips
   8. file://localhost/home/law/INSTALL/faq.html#x86eh
   9. file://localhost/home/law/INSTALL/faq.html#hpcompare
  10. file://localhost/home/law/INSTALL/faq.html#makebugs
  11. file://localhost/home/law/INSTALL/faq.html#rpath
  12. file://localhost/home/law/INSTALL/faq.html#rpath
  13. file://localhost/home/law/INSTALL/faq.html#dejagnu
  14. file://localhost/home/law/INSTALL/faq.html#cross
  15. file://localhost/home/law/INSTALL/faq.html#multiple
  16. file://localhost/home/law/INSTALL/faq.html#snapshot
  17. file://localhost/home/law/INSTALL/faq.html#linuxkernel
  18. file://localhost/home/law/INSTALL/faq.html#memexhausted
  19. file://localhost/home/law/INSTALL/faq.html#gas
  20. file://localhost/home/law/INSTALL/faq.html#rh5.0
  21. file://localhost/home/law/INSTALL/faq.html#x86solaris
  22. file://localhost/home/law/INSTALL/faq.html#windows
  23. file://localhost/home/law/INSTALL/faq.html#environ
  24. file://localhost/home/law/INSTALL/faq.html#kde
  25. file://localhost/home/law/INSTALL/faq.html#open-development
  26. file://localhost/home/law/INSTALL/faq.html#cathedral-vs-bazaar
  27. http://locke.ccil.org/~esr/writings/cathedral.html
  28. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz
  29. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz
  30. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz
  31. ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz
  32. ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz
  33. ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1
  34. file://localhost/home/law/INSTALL/index.html#mailinglists
  35. http://www.cygnus.com/ml/egcs/1997-Dec/0594.html
  36. http://www.xraylith.wisc.edu/~khan/software/gnu-win32
  37. file://localhost/home/law/INSTALL/index.html