diff options
Diffstat (limited to 'INSTALL/FAQ')
| -rw-r--r-- | INSTALL/FAQ | 322 |
1 files changed, 0 insertions, 322 deletions
diff --git a/INSTALL/FAQ b/INSTALL/FAQ deleted file mode 100644 index 343243ddb17..00000000000 --- a/INSTALL/FAQ +++ /dev/null @@ -1,322 +0,0 @@ -egcs Frequently Asked Questions - - -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 (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[1] approach to its -development: We're going to be making snapshots publically 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. - -cathedral-vs-bazaar[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 `` http://locke.ccil.org/~esr/writings/cathedral.html" The - Cathedral and the Bazaar''. The paper is a useful starting point - for discussions. - - - -bits/libc-lock.h: No such file or directory -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. - -Late breaking news: we may have at least a partial solution for these -problems. So this FAQ entry may no longer be needed. - - -`_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 in 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.0.1.15 or newer. -"ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz binutils-2.8.0.1.15 source -ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz binutils-2.8.0.1.15 x86 binary for libc5 -ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz binutils-2.8.0.1.15 x86 binary for glibc2 -Or, you can try a -ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz 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 -<a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971028.tar.gz"> -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 <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1"> -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 <a href="index.html#mailinglists"> -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. - -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/process.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. - - -egcs does not work on Red Hat 5.0 - egcs does not currently work with Red Hat 5.0; we'll update this -entry with more information as it becomes available. - - -Last modified: December 2, 1997 |