| <html> |
| <head> |
| <title>egcs Frequently Asked Questions</title> |
| </head> |
| <body bgcolor="white"> |
| <h1 align="center">egcs Frequently Asked Questions</h1> |
| |
| <ol> |
| <li><a href="#gcc-2-diff">How is egcs different from gcc2?</a> |
| <li><a href="#open-development">What is an open development model?</a> |
| <li><a href="#release-fork">Releases and Forking</a> |
| <li><a href="#libc-lock">bits/libc-lock.h: No such file or directory</a> |
| <li><a href="#morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a> |
| <li><a href="#fortran">Problems building the Fortran compiler</a> |
| <li><a href="#mips">Problems building on MIPS platforms</a> |
| <li><a href="#x86eh">Problems with exception handling on x86 platforms</a> |
| <li><a href="#hpcompare">Bootstrap comparison failures on HPs</a> |
| <li><a href="#makebugs">Bootstrap loops rebuilding cc1 over and over</a> |
| <li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a> |
| <li><a href="#rpath">libstdc++/libio tests fail badly with --enable-shared</a> |
| <li><a href="#dejagnu">Unable to run the testsuite</a> |
| <li><a href="#cross">How to build a cross compiler</a> |
| <li><a href="#multiple">How to install both gcc2 and egcs</a> |
| <li><a href="#snapshot">Snapshots, how, when, why</a> |
| <li><a href="#linuxkernel">Problems building Linux kernels</a> |
| <li><a href="#memexhausted">Virtual memory exhausted</a> |
| <li><a href="#gas">GCC can not find GAS</a> |
| <li><a href="#rh5.0">egcs does not work on Red Hat 5.0</a> |
| <li><a href="#x86solaris">Unable to bootstrap on x86 Solaris2.{5,6}</a> |
| <li><a href="#windows">EGCS with Windows</a> |
| <li><a href="#os2">EGCS with OS/2</a> |
| <li><a href="#environ">cpp: Usage:... Error</a> |
| <li><a href="#kde">EGCS will not build KDE</a> |
| <li><a href="#friend">Friend Templates</a> |
| <li><a href="#libg++">Where to find libg++</a> |
| <li><a href="#autoconf/bison++">Why do I need autoconf & bison</a> |
| <li><a href="#aix">EGCS does not work on AIX 4.3</a> |
| <li><a href="#gdb">Problems debugging egcs code</a> |
| <li><a href="#conflicts">Conflicts when using cvs update </a> |
| </ol> |
| |
| <hr> |
| <h2><a name="gcc-2-diff">How is egcs be different from gcc2?</a></h2> |
| |
| <p>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. |
| |
| <p>In brief, the three biggest differences between egcs and gcc2 are: |
| |
| <ul> |
| <li>More rexamination of basic architectual decisions of |
| gcc and an interest in adding new optimizations; |
| |
| <li>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 |
| |
| <li>An open development model (<a |
| href="#open-development">see below</a>) for the development process. |
| </ul> |
| |
| <p>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. |
| |
| |
| <p>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. |
| |
| <hr> |
| <h2><a name="open-development">What is an open development model?</a></h2> |
| |
| <p>With egcs, we are going to try a bazaar style<a |
| href="#cathedral-vs-bazaar"><b>[1]</b></a> 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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <blockquote> |
| <a name="cathedral-vs-bazaar"><b>[1]</b></a> |
| 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 <b>cathedral</b> development model versus a <b>bazaar</b> |
| development model. The paper is written by Eric S. Raymond, it is |
| called ``<a |
| href="http://locke.ccil.org/~esr/writings/cathedral.html">The |
| Cathedral and the Bazaar</a>''. The paper is a useful starting point |
| for discussions. |
| </blockquote> |
| |
| <hr> |
| <h2><a name="release-fork">Releases and Forking?</a></h2> |
| <p>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. |
| |
| <pre> |
| 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. |
| </pre> |
| |
| <hr> |
| <h2><a name="libc-lock">bits/libc-lock.h: No such file or directory</a></h2> |
| <p>This entry should be obsolete, egcs should handle these beta versions of |
| glibc2 correctly. |
| |
| <p>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). |
| |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <h2><a name="morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <h2><a name="fortran">Problems building the Fortran compiler</a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <h2><a name="mips">Problems building on MIPS platforms</a></h2> |
| <p>egcs requires the use of GAS on all versions of Irix, except Irix 6 due |
| to limitations in older Irix assemblers. |
| |
| <p> Either of these messages indicates that you are using the MIPS assembler |
| when instead you should be using GAS. |
| |
| <pre> |
| as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal |
| .4byte $LECIE1-$LSCIE1 |
| as0: Error: ./libgcc2.c, line 1:malformed statement |
| </pre> |
| |
| <hr> |
| <pre> |
| as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression |
| .word $LECIE1-$LSCIE1 |
| |
| </pre> |
| |
| |
| <p> For Irix 6, you should use the native assembler as GAS is not supported |
| on Irix 6. |
| |
| <hr> |
| <h2> <a name="x86eh">Problems with exception handling on x86 platforms</a></h2> |
| <p>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. |
| |
| <p>We recommend binutils-2.8.1.0.15 or newer. |
| <br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.20.tar.gz"> binutils-2.8.1.0.20 source</a> |
| <br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.20.bin.tar.gz"> binutils-2.8.1.0.20 x86 binary for libc5</a> |
| <br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.20.glibc.bin.tar.gz"> binutils-2.8.1.0.20 x86 binary for glibc2</a> |
| Or, you can try a |
| <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz"> binutils snapshot</a>; however, be aware that the binutils snapshot is untested |
| and may not work (or even build). Use it at your own risk. |
| |
| <hr> |
| <h2> <a name="hpcompare">Bootstrap comparison failures on HPs</a></h2> |
| <p>If you bootstrap the compiler on hpux10 using the HP assembler instead of |
| gas, every file will fail the comparison test. |
| |
| <p>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. |
| |
| <p>Odds are your compiler is fine, but there's no way to be certain. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="makebugs">Bootstrap loops rebuilding cc1 over and over</a></h2> |
| <p>When building egcs, the build process loops rebuilding cc1 over and |
| over again. This happens on mips-sgi-irix5.2, and possibly other platforms. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="rpath">Dynamic linker is unable to find GCC libraries</a></h2> |
| <p>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. |
| |
| <p>GCC does not specify a runpath so that the dynamic linker can find dynamic |
| libraries at runtime. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="dejagnu">Unable to run the testsuite</a></h2> |
| <p>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 |
| <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz"> |
| dejagnu snapshot</a> available until a new version of dejagnu can be released. |
| |
| <hr> |
| <h2> <a name="cross">How to build a cross compiler</a></h2> |
| <p> Building cross compilers is a rather complex undertaking because they |
| usually need additional software (cross assembler, cross linker, target |
| libraries, target include files, etc). |
| |
| <p> We recommend reading the <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1"> |
| crossgcc FAQ</a> for information about building cross compilers. |
| |
| <p> 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. |
| |
| <p> 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. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="snapshot">Snapshots, how, when, why</a></h2> |
| <p> 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. |
| |
| <p>If you plan on downloading and using snapshots, we highly recommend you |
| subscribe to the egcs mailing lists. See <a href="index.html#mailinglists"> |
| mailing lists</a> on the main egcs page for instructions on how to subscribe. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="multiple">How to install both egcs and gcc2</a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="linuxkernel">Problems building Linux kernels</a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <p>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?!? |
| |
| <p>You may get errors with the X driver of the form |
| <pre> |
| _X11TransSocketUNIXConnect: Can't connect: errno = 111 |
| </pre> |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="memexhausted">Virtual memory exhausted error</a></h2> |
| <p> 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. |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="gas">GCC can not find GAS</a></h2> |
| <p>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. |
| |
| <hr> |
| <h2> <a name="rh5.0">egcs does not work on Red Hat 5.0</a></h2> |
| <p> This entry is obsolete with the release of egcs-1.0.1 which should |
| handle Red Hat 5.0 correctly. |
| |
| <p> 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. |
| |
| <p> You may want to try this |
| <a href="http://www.cygnus.com/ml/egcs/1997-Dec/0594.html"> proposed patch</a> |
| for Red Hat 5.0. Please let us know if you use this patch and whether or |
| not it works. |
| |
| <hr> |
| <h2> <a name="x86solaris">Unable to bootstrap on x86 Solaris 2.{5,6}</a></h2> |
| <p> This entry is obsolete with the release of egcs-1.0.1 which should |
| handle x86 Solaris systems correctly. |
| |
| <p>This patch should fix the problem |
| |
| <pre> |
| 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 |
| </pre> |
| |
| <hr> |
| <h2> <a name="windows">EGCS with Windows</a></h2> |
| <p>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. |
| <a href="http://www.xraylith.wisc.edu/~khan/software/gnu-win32">GNU Win32 related projects</a> |
| |
| <hr> |
| <h2> <a name="os2">EGCS with OS/2</a></h2> |
| <p>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 <a href="http://www.goof.com/pcg/os2">http://www.goof.com/pcg/os2</a>. |
| |
| <hr> |
| <h2> <a name="environ">cpp: Usage:... Error</a></h2> |
| <p>If you get an error like this when building egcs (particularly when building |
| __mulsi3), then you likely have a problem with your environment variables. |
| <pre> |
| cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp |
| [switches] input output |
| </pre> |
| |
| <p>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. |
| |
| <hr> |
| <h2> <a name="kde">EGCS will not build KDE</a></h2> |
| <p> 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: |
| |
| <pre> |
| struct S { S(int); } |
| void f() { new S[3](6); } |
| </pre> |
| |
| <p>However, this construct is not allowed by the ANSI/ISO Standard, and |
| is no longer accepted by g++. |
| |
| <p> KDE uses such constructs and therefore will not build with egcs; note |
| patches are available to fix KDE. |
| |
| <hr> |
| <h2> <a name="friend">Friend Templates<a></h2> |
| <p>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. |
| |
| <hr> |
| <h2> <a name="libg++">Where to find libg++<a></h2> |
| <p>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. |
| |
| <p>If you do need libg++ you can get a libg++ snapshot which works with egcs |
| from <a href="ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980119.tar.gz"> |
| ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1-980119.tar.gz</a> |
| |
| <hr> |
| <h2> <a name="autoconf/bison++">Why do I need autoconf/bison<a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <p>If you do not have autoconf, bison, etc, then you can issue the |
| following commands to touch all the generated files. |
| |
| <pre> |
| 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 |
| </pre> |
| |
| <hr> |
| <h2> <a name="aix">EGCS does not work on AIX 4.3<a></h2> |
| <p>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. |
| |
| <hr> |
| <h2><a name="gdb">Problems debugging egcs code</a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <h2><a name="conflicts">Conflicts when using cvs update</a></h2> |
| <p>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. |
| |
| <p>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. |
| |
| <hr> |
| <p><a href="index.html">Return to the egcs home page</a> |
| <p><i>Last modified: March 04, 1998</i> |
| |
| <!--#include virtual="/glimpsebox.html"--> |
| </body> |
| </html> |