faq.html patch

Rich Churcher rich.c@es.co.nz
Sat Jan 9 18:39:00 GMT 1999


faq.html now reorganised into five sections: General information, Installation, Testsuite problems, Platform-specific issues, Miscellaneous.

Hope everything goes smoothly this time...

Cheers,

Rich.
--
rich.c@es.co.nz
ICQ# 6443250


Index: faq.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/faq.html,v
retrieving revision 1.92
diff -c -3 -p -r1.92 faq.html
*** faq.html	1999/01/07 13:58:20	1.92
--- faq.html	1999/01/10 01:10:17
*************** comp.lang.c++ FAQ</a>, and the 
*** 14,77 ****
  comp.std.c++ FAQ</a>.
  
  <hr>
  <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="#bugreport">How to report bugs</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="#broken">Problems with code that works with other compilers or earlier gcc releases</a>
!   <ul>
!     <li><a href="#fdzero">FD_ZERO macro</a>
!     <li><a href="#octave">Octave 2.0.13 does not compile</a>
!   </ul>
!   <li><a href="#asmclobber">Problems with <tt>Invalid `asm' statement</tt>s</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 GNU as/GNU ld</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="#friend">Friend Templates</a>
!   <li><a href="#libg++">Where to find libg++</a>
!   <li><a href="#generated_files">Why do I need autoconf, bison, xgettext, automake, etc </a>
!   <li><a href="X11R6">How do I compile X11 headers with g++</a>
!   <li><a href="#aixas">Assembler error on AIX 4.3.0</a>
!   <li><a href="#gdb">Problems debugging EGCS code</a>
!   <li><a href="#conflicts">Conflicts when using cvs update </a>
!   <li><a href="#gnat">Using EGCS with GNAT/Ada</a>
!   <li><a href="#gpc">Using EGCS with GNU Pascal</a>
!   <li><a href="#cvssnapshots">Using CVS to download snapshots </a>
!   <li><a href="#picflag-needed">Why can't I build a shared library?</a>
!   <li><a href="#sunos4ld">Linker core dumps on SunOS4</a>
!   <li><a href="#axparch">Assembler errors on Alpha targets</a>
!   <li><a href="#sig11">Signal 11 on Linux</a>
!   <li><a href="#bigtoc">Link failures using -bbigtoc on AIX 4.1</a>
!   <li><a href="spam.html">Dealing with spam on the lists</a>
!   <li><a href="#testoptions">How do I pass flags like
!          <code>-fnew-abi</code> to the testsuite?</a>
!   <li><a href="#o32abi">Does EGCS support the O32 ABI on IRIX 6?</a>
!   <li><a href="#irix6n32bugs">Bugs in N32 and N64 ABI implementation on IRIX 6</a>
!   <li><a href="#aix43">Unable to bootstrap egcs-1.1 on AIX 4.3</a>
!   <li><a href="#irixlinks">Links to other FAQs for GCC on IRIX platforms?</a>
!   <li><a href="#squangle">How to work around too long C++ symbol names? 
! 	 (<tt>-fsquangle</tt>)</a>
!   <li><a href="#multipletests">How can I run the test suite with multiple options?</a>
!   <li><a href="#aixcoff">AIX 4.3 archive libraries ("not a COFF file")</a>
!   <li><a href="#next">Problems with egcs on NEXTSTEP 3.x systems</a>
! </ol>
! 
  <hr>
  <h2><a name="gcc-2-diff">How is EGCS different from gcc2?</a></h2>
  
--- 14,37 ----
  comp.std.c++ FAQ</a>.
  
  <hr>
+ <h1>Sections:</h1>
+ <ul>
+ 	<li><a href="#general">General information</a>
+ 	<li><a href="#installation">Installation</a>
+ 	<li><a href="#testsuite">Testsuite problems</a>
+ 	<li><a href="#platform">Platform-specific issues</a>
+ 	<li><a href="#misc">Miscellaneous</a>
+ </ul>
+ <hr>	
+ 
+ <a name="general"></a>
+ <h1>General information</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="#bugreport">How to report bugs</a>
! </ol> 
  <hr>
  <h2><a name="gcc-2-diff">How is EGCS different from gcc2?</a></h2>
  
*************** compressed CPP output as an attachment t
*** 245,253 ****
  <p>The egcs lists have message size limits (40 kbytes) and uncompressed bug
  reports over those limits will be bounced.  Most compressed but reports are
  allowed to exceed the limits unless they are unreasonably huge.
- 
  
  <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
--- 205,224 ----
  <p>The egcs lists have message size limits (40 kbytes) and uncompressed bug
  reports over those limits will be bounced.  Most compressed but reports are
  allowed to exceed the limits unless they are unreasonably huge.
  
  <hr>
+  <a name="installation"></a>
+ <h1>Installation</h1>
+ <ol>
+   <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="#multiple">How to install both gcc2 and EGCS</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="#gas">GCC can not find GNU as/GNU ld</a>
+   <li><a href="#environ">cpp: Usage:... Error</a>
+ </ol>
+ <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
*************** binutils or to Red Hat 5.0; we'll provid
*** 273,278 ****
--- 244,405 ----
  available.                                                               
  
  <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="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 explanation is that if you always pass a -R option to the
+ linker, then your programs become dependent on directories which
+ may be NFS mounted, and programs may hang unnecessarily when an
+ NFS server goes down.
+ 
+ <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="gas">GCC can not find GNU as/GNU ld</a></h2>
+ <p>To ensure that EGCS finds the GNU assembler (the GNU loader), which
+ are required by <a href="install/specific.html">some configurations</A>,
+ you should configure these with the same --prefix option as you used
+ for EGCS.  Then build & install GNU as (GNU ld) and proceed with
+ building EGCS.
+ 
+ <p>Another alternative is to create links to GNU as and ld in any of
+ the directories printed by the command `<tt>gcc -print-search-dirs |
+ grep '^programs:'</tt>'.  The link to `<tt>ld</tt>' should be named
+ `<tt>real-ld</tt>' if `<tt>ld</tt>' already exists.
+ 
+ <p>Pre-1.2 snapshots of egcs allow you to specify the full pathname of
+ the assembler and the linker to use.  The configure flags are
+ `<tt>--with-as=/path/to/as</tt>' and `<tt>--with-ld=/path/to/ld</tt>'.
+ EGCS will try to use these pathnames before looking for `<tt>as</tt>'
+ or `<tt>(real-)ld</tt>' in the standard search dirs.  If, at
+ configure-time, the specified programs are found to be GNU utilities,
+ `<tt>--with-gnu-as</tt>' and `<tt>--with-gnu-ld</tt>' need not be
+ used; these flags will be auto-detected.
+ 
+ <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.
+ 
+ <p>Also note '::' in these paths will also cause similar problems.
+ 
+ 
+ <hr>
+ <a name="testsuite"></a>
+ <h1>Testsuite problems</h1>
+ <ol>
+   <li><a href="#dejagnu">Unable to run the testsuite</a>
+   <li><a href="#testoptions">How do I pass flags like
+          <code>-fnew-abi</code> to the testsuite?</a>
+   <li><a href="#multipletests">How can I run the test suite with multiple options?</a>
+ </ol>
+ 
+ <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-980528.tar.gz ">
+ dejagnu snapshot</a> available until a new version of dejagnu can be released.
+ 
+ <hr>
+ <h2><a name="testoptions">How do I pass flags like
+ <code>-fnew-abi</code> to the testsuite?</a></h2>
+ <p>If you invoke <code>runtest</code> directly, you can use the
+ <code>--tool_opts</code> option, e.g:
+ <pre>
+   runtest --tool_opts "-fnew-abi -fno-honor-std" <other options>
+ </pre>
+ Or, if you use <code>make check</code> you can use the
+ <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:
+ <pre>
+   make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++
+ </pre>
+ 
+ <hr>
+ <h2><a name="multipletests"> How can I run the test suite with multiple options? </a></h2>
+ 
+ <p>If you invoke <code>runtest</code> directly, you can use the
+ <code>--target_board</code> option, e.g:
+ <pre>
+   runtest --target_board "unix{-fPIC,-fpic,}" <other options>
+ </pre>
+ Or, if you use <code>make check</code> you can use the
+ <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:
+ <pre>
+   make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gcc
+ </pre>
+ <p>Either of these examples will run the tests three times.   Once 
+ with <code>-fPIC</code>, once with <code>-fpic</code>, and once with 
+ no additional flags.
+ <p>This technique is particularly useful on multilibbed targets.
+ 
+ <hr>
+ <a name="platform"></a>
+ <h1>Platform-specific issues</h1>
+ <ol>    	  
+    <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="#asmclobber">Problems with <tt>Invalid `asm' statement</tt>s</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="#linuxkernel">Problems building Linux kernels</a>  
+   <li><a href="#windows">EGCS with Windows</a>  
+   <li><a href="#os2">EGCS with OS/2</a>
+   <li><a href="X11R6">How do I compile X11 headers with g++</a>  
+   <li><a href="#sunos4ld">Linker core dumps on SunOS4</a>
+   <li><a href="#axparch">Assembler errors on Alpha targets</a>
+   <li><a href="#sig11">Signal 11 on Linux</a>
+   <li><a href="#bigtoc">Link failures using -bbigtoc on AIX 4.1</a>
+   <li><a href="#aixcoff">AIX 4.3 archive libraries ("not a COFF file")</a>
+   <li><a href="#aix43">Unable to bootstrap egcs-1.1 on AIX 4.3</a>
+   <li><a href="#aixas">Assembler error on AIX 4.3.0</a>
+   <li><a href="#o32abi">Does EGCS support the O32 ABI on IRIX 6?</a>
+   <li><a href="#irix6n32bugs">Bugs in N32 and N64 ABI implementation on IRIX 6</a>
+   <li><a href="#irixlinks">Links to other FAQs for GCC on IRIX platforms?</a>
+   <li><a href="#next">Problems with egcs on NEXTSTEP 3.x systems</a>
+   <li><a href="#cross">How to build a cross compiler</a>
+ </ol>
+ 
+ <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.
*************** aware that snapshots are in general unte
*** 313,357 ****
  build).  Use them at your own risk.
  
  <hr>
- <h2><a name="broken">Problems with code that works with other compilers or earlier gcc releases</a></h2>
- 
- <p>Unfortunately, improvements in tools that are widely used are
- sooner or later bound to break <em>something</em>.  Sometimes, the
- code that breaks was wrong, and then that code should be fixed, even
- if it works for earlier versions of gcc or other compilers.  The
- following problems with some releases of widely used packages have
- been identified:
- 
- <ul>
-   <li><strong><a name="fdzero">FD_ZERO macro</a></strong> <p>The
-   FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses <a
-   href="#asmclobber">invalid asm clobbers</a>. The following rewrite
-   by Ulrich Drepper <drepper@cygnus.com> should fix this for
-   glibc 2.0:
- 
- <PRE>
-   # define __FD_ZERO(fdsetp) \
-     do { \
-       int __d0, __d1; \
-     __asm__ __volatile__ ("cld; rep; stosl" \
- 			  : "=m" (((__fd_mask *) \
- 				   (fdsetp))[__FDELT (__FD_SETSIZE)]), \
- 			    "=&c" (__d0), "=&D" (__d1) \
- 			  : "a" (0), "1" (sizeof (__fd_set) \
- 					  / sizeof (__fd_mask)), \
- 			    "2" ((__fd_mask *) (fdsetp)) \
- 			  : "memory"); \
-     } while (0)
- </PRE>
- 
-   <li><a name="octave">Octave 2.0.13 does not compile</a>
-   <p>Apparently Octave 2.0.13 uses some C++ features which have been
-   obsoleted and thus fails to build with egcs-1.1 and later. This <a
-   href=" http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/270 ">patch
-   to Octave</a> should fix this.
- </ul>
- 
- <hr>
  <h2><a name="asmclobber">Problems with invalid `asm' statements</a></h2>
  <p>Previous releases of gcc (for example, gcc-2.7.2.<i>X</i>) did not
  detect as invalid a clobber specifier that clobbered an operand.
--- 440,445 ----
*************** make program; however, you may have succ
*** 454,547 ****
  you do not have GNU make available.
  
  <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 explanation is that if you always pass a -R option to the
- linker, then your programs become dependent on directories which
- may be NFS mounted, and programs may hang unnecessarily when an
- NFS server goes down.
- 
- <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-980528.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 ">
- 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 have tried to build a 2.0.xx kernel for Intel machines with
  EGCS, then you are on your own.  The 2.0.xx kernels are to be built only
--- 542,547 ----
*************** more aggressively . The newer 2.1.x kern
*** 578,583 ****
--- 578,801 ----
  also work in 2.0.32.
  
  <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="X11R6">How do I compile X11 headers with g++</h2>
+ <p>
+ When compiling X11 headers with a egcs 2.92.33 or newer, g++ will
+ complain that types are missing. These headers assume that omitting
+ the type means 'int'; this assumption is wrong for C++.
+ <p>
+ g++ accepts such (illegal) constructs with the option -fpermissive;
+ it will assume that missing type is 'int' (as defined by the C89
+ standard).
+ <p>
+ Since the upcoming C99 standard also obsoletes the implicit type
+ assumptions, the X11 headers have to get fixed eventually.
+ <p>
+ 
+ <hr>
+ <h2><a name="sunos4ld">SunOS4 Linker core dumps</a></h2>
+ <p>A bug in the SunOS4 linker will cause it to crash when linking -fPIC compiled
+ objects.
+ 
+ <p>To fix this problem you can either use the most recent version of binutils or
+ get the latest SunOS4 linker patch (patch ID 100170-10) from Sun's patch site.
+ 
+ <hr>
+ <h2><a name="axparch">Assembler errors on Alpha targets</a></h2>
+ 
+ <p> Error: Unknown pseudo-op:  `.arch'
+ <br>Linux/Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may see
+ errors of this sort.  This is a signal that a new assembler is needed
+ if you want to generate BWX insns for your machine.
+ 
+ <p>The version shipped with Red Hat 4.2 (2.7.0.2) has a fault wherein
+ it will silently generate incorrect code.  The version shipped with
+ Red Hat 5.0 (2.8.0.1) is not broken, but required an extra -m21164a
+ argument on the command-line.  In order to visibly trap 2.7.0.2,
+ I now issue DEC's .arch pseudo into the assembly.  Relieving the
+ problem of mucking with command-line arguments for 2.8.0.1 is a
+ pleasant side effect.
+ 
+ <p>If you've got Red Hat 5.0 installed, you may grab binutils 2.9.1
+ and be happy.  If you've got Red Hat 4.2, bugs make it much harder
+ to upgrade pieces on your own, and you are better off upgrading
+ the entire system.
+ 
+ <p>In either case, your problem may be bypassed by not emitting BWX
+ code by default.  Do this by using
+ <pre>
+ 	configure alphaev5-unknown-linux-gnulibc1
+ </pre>
+ if you have RH 4.2, or
+ <pre>
+ 	configure alphaev5-unknown-linux-gnu
+ </pre>
+ if you have RH 5.0.
+ 
+ <p> Error: macro requires $at register while noat in effect
+ <br>This error also indicates that you should upgrade to a newer version of
+ the assembler, 2.9 or later.  If you can not upgrade the assembler, the
+ compiler option "-Wa,-m21164a" may work around this problem.
+ 
+ <hr>
+ <h2><a name="sig11">Signal 11 on Linux</a></h2>
+ <p> If you receive Signal 11 errors when building on Linux, then it is possible
+ you have a hardware problem.  Further information on this can be found on
+ <a href=" http://www.bitwizard.nl/sig11/ ">www.bitwizard.nl.</a>
+ 
+ <hr>
+ <h2><a name="bigtoc">Link failures using -bbigtoc on AIX 4.1</a></h2>
+ <p>Some versions of the AIX binder (linker) can fail with a relocation
+ overflow severe error when the -bbigtoc option is used to link
+ GCC-produced object files into an executable that overflows the TOC.  A fix
+ for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
+ available from IBM Customer Support and from its
+ <a href=" http://service.boulder.ibm.com/ ">service.boulder.ibm.com</a>
+ website as PTF U455193.
+ 
+ <hr>
+ <h2><a name="aixcoff">AIX 4.3 archive libraries ("not a COFF file")</a></h2>
+ <p>AIX 4.3 utilizes a new "large format" archive to support both
+ 32-bit and 64-bit object modules.  The routines provided in AIX 4.3.0 and
+ AIX 4.3.1 to parse archive libraries did not handle the new format correctly.
+ These routines are used by GCC and result in error messages during linking
+ such as "not a COFF file".  The version of the routines shipped
+ with AIX 4.3.1 should work for a 32-bit environment.  The <tt>-g</tt> option
+ of the archive command may be used to create archives of 32-bit objects
+ using the original "small format".  A correct version of the routines is
+ shipped with AIX 4.3.2.
+ 
+ <hr>
+ <h2><a name="aix43">Unable to bootstrap egcs-1.1 on AIX 4.3</a></h2>
+ <p>The complete egcs-1.1 distribution will try to build 64-bit versions of
+ all runtime libraries which will fail for libstdc++.  If only a C compiler is
+ desired, configure and build egcs-core-1.1.  If other languages are needed,
+ configure as if the system were rs6000-ibm-aix4.2, which will disable
+ 64-bit support.  This will be fixed in the egcs-1.1.1 release.
+ 
+ <hr>
+ <h2><a name="aixas">Assembler error on AIX 4.3.0</a></h2>
+ <p>The initial assembler shipped with AIX 4.3.0 generates incorrect object
+ files.  A fix for APAR IX74254 (64BIT DISASSEMBLED OUPUT FROM COMPILER FAILS
+ TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
+ <a href=" http://service.boulder.ibm.com/ ">service.boulder.ibm.com</a>
+ website as PTF U453956.  This fix is incorporated in AIX 4.3.1 and above.
+ 
+ <hr>
+ <h2><a name="o32abi">Does EGCS support the O32 ABI on IRIX 6</a></h2>
+ <p>Gcc does not currently support generating O32 ABI binaries in the
+ mips-sgi-irix6 configurations.
+ 
+ <p>It used to be possible to create a gcc with O32 ABI only support by
+ configuring it for the mips-sgi-irix5 target.  See <a
+ href="#irixlinks">Links to other FAQs for GCC on IRIX platforms</a> for details.
+   
+ <hr>
+ <h2><a name="irix6n32bugs">Bugs in N32 and N64 ABI implementation on IRIX 6</a></h2>
+ <p>Gcc does not correctly pass/return structures which are
+ smaller than 16 bytes and which are not 8 bytes. The problem is very
+ involved and difficult to fix. It affects a number of other targets also,
+ but IRIX 6 is affected the most, because it is a 64 bit target, and 4 byte
+ structures are common. The exact problem is that structures are being padded
+ at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes
+ of the register when it should be loaded into the upper 4 bytes of the
+ register. 
+ 
+ <p>Gcc is consistent with itself, but not consistent with the SGI C compiler
+ [and the SGI supplied runtime libraries], so the only failures that can
+ happen are when there are library functions that take/return such
+ structures. There are very few such library functions. I can only recall
+ seeing two of them: inet_ntoa, and semctl. 
+ 
+ <hr>
+ <h2><a name="irixlinks">Links to other FAQs for GCC on IRIX platforms </a></h2>
+ <p><a href=" http://reality.sgi.com/ariel/freeware/ "> 
+ http://reality.sgi.com/ariel/freeware </a>
+ 
+ <hr>
+ <h2><a name="next">Problems with EGCS on NEXTSTEP 3.x systems</a></h2>
+ <p>On NEXTSTEP 3.x where x < 3 the build of egcs will abort during  
+ stage1 with an error message like this:
+ 
+ <pre>
+ _eh
+ /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section
+ /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character  
+ valued 95 (_).
+ </pre>
+ 
+ <p>The reason for this is the fact that NeXT's assembler for these  
+ versions of the operating system does not support the .section  
+ pseudo op that's needed for full C++ exception functionality.
+ 
+ As NeXT's assembler is a derived work from GNU as, a free  
+ replacement that does can be obtained at 
+ <a href=" ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz "> ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz </a>.
+ 
+ 
+ <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 ">
+ 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>
+ <a name="misc"></a>  
+ <h1>Miscellaneous</h1>
+ <ol>
+   <li><a href="#memexhausted">Virtual memory exhausted</a>
+   <li><a href="#broken">Problems with code that works with other compilers or earlier gcc releases</a>
+   <ul>
+     <li><a href="#fdzero">FD_ZERO macro</a>
+     <li><a href="#octave">Octave 2.0.13 does not compile</a>
+   </ul>
+   <li><a href="#snapshot">Snapshots, how, when, why</a>
+   <li><a href="#friend">Friend Templates</a>
+   <li><a href="#libg++">Where to find libg++</a>
+   <li><a href="#generated_files">Why do I need autoconf, bison, xgettext, automake, etc </a>
+   <li><a href="#gdb">Problems debugging EGCS code</a>
+   <li><a href="#conflicts">Conflicts when using cvs update </a>
+   <li><a href="#gnat">Using EGCS with GNAT/Ada</a>
+   <li><a href="#gpc">Using EGCS with GNU Pascal</a>
+   <li><a href="#cvssnapshots">Using CVS to download snapshots </a>
+   <li><a href="#picflag-needed">Why can't I build a shared library?</a>
+   <li><a href="spam.html">Dealing with spam on the lists</a>
+   <li><a href="#squangle">How to work around too long C++ symbol names? 
+ 	 (<tt>-fsquangle</tt>)</a>
+ </ol>
+ 
+ <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
*************** STL.  Also note that -Wall includes -Wre
*** 589,644 ****
  will need to specify -Wno-return-type to turn it off.
  
  <hr>
! <h2><a name="gas">GCC can not find GNU as/GNU ld</a></h2>
! <p>To ensure that EGCS finds the GNU assembler (the GNU loader), which
! are required by <a href="install/specific.html">some configurations</A>,
! you should configure these with the same --prefix option as you used
! for EGCS.  Then build & install GNU as (GNU ld) and proceed with
! building EGCS.
  
! <p>Another alternative is to create links to GNU as and ld in any of
! the directories printed by the command `<tt>gcc -print-search-dirs |
! grep '^programs:'</tt>'.  The link to `<tt>ld</tt>' should be named
! `<tt>real-ld</tt>' if `<tt>ld</tt>' already exists.
  
! <p>Pre-1.2 snapshots of egcs allow you to specify the full pathname of
! the assembler and the linker to use.  The configure flags are
! `<tt>--with-as=/path/to/as</tt>' and `<tt>--with-ld=/path/to/ld</tt>'.
! EGCS will try to use these pathnames before looking for `<tt>as</tt>'
! or `<tt>(real-)ld</tt>' in the standard search dirs.  If, at
! configure-time, the specified programs are found to be GNU utilities,
! `<tt>--with-gnu-as</tt>' and `<tt>--with-gnu-ld</tt>' need not be
! used; these flags will be auto-detected.
  
- <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.
  
- <p>Also note '::' in these paths will also cause similar problems.
  
  <hr>
  <h2><a name="friend">Friend Templates</a></h2>
--- 807,869 ----
  will need to specify -Wno-return-type to turn it off.
  
  <hr>
! <h2><a name="broken">Problems with code that works with other compilers or earlier gcc releases</a></h2>
  
! <p>Unfortunately, improvements in tools that are widely used are
! sooner or later bound to break <em>something</em>.  Sometimes, the
! code that breaks was wrong, and then that code should be fixed, even
! if it works for earlier versions of gcc or other compilers.  The
! following problems with some releases of widely used packages have
! been identified:
! 
! <ul>
!   <li><strong><a name="fdzero">FD_ZERO macro</a></strong> <p>The
!   FD_ZERO macro in (e.g.) libc-5.4.46 is incorrect. It uses <a
!   href="#asmclobber">invalid asm clobbers</a>. The following rewrite
!   by Ulrich Drepper <drepper@cygnus.com> should fix this for
!   glibc 2.0:
! 
! <PRE>
!   # define __FD_ZERO(fdsetp) \
!     do { \
!       int __d0, __d1; \
!     __asm__ __volatile__ ("cld; rep; stosl" \
! 			  : "=m" (((__fd_mask *) \
! 				   (fdsetp))[__FDELT (__FD_SETSIZE)]), \
! 			    "=&c" (__d0), "=&D" (__d1) \
! 			  : "a" (0), "1" (sizeof (__fd_set) \
! 					  / sizeof (__fd_mask)), \
! 			    "2" ((__fd_mask *) (fdsetp)) \
! 			  : "memory"); \
!     } while (0)
! </PRE>
  
!   <li><a name="octave">Octave 2.0.13 does not compile</a>
!   <p>Apparently Octave 2.0.13 uses some C++ features which have been
!   obsoleted and thus fails to build with egcs-1.1 and later. This <a
!   href=" http://www.che.wisc.edu/octave/mailing-lists/bug-octave/1998/270 ">patch
!   to Octave</a> should fix this.
! </ul>
  
  
  <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="friend">Friend Templates</a></h2>
*************** ftp://egcs.cygnus.com/pub/egcs/infrastru
*** 751,777 ****
  </p>
  
  <hr>
! <h2><a name="X11R6">How do I compile X11 headers with g++</h2>
! <p>
! When compiling X11 headers with a egcs 2.92.33 or newer, g++ will
! complain that types are missing. These headers assume that omitting
! the type means 'int'; this assumption is wrong for C++.
! <p>
! g++ accepts such (illegal) constructs with the option -fpermissive;
! it will assume that missing type is 'int' (as defined by the C89
! standard).
! <p>
! Since the upcoming C99 standard also obsoletes the implicit type
! assumptions, the X11 headers have to get fixed eventually.
! <p>
  
! <hr>
! <h2><a name="aixas">Assembler error on AIX 4.3.0</a></h2>
! <p>The initial assembler shipped with AIX 4.3.0 generates incorrect object
! files.  A fix for APAR IX74254 (64BIT DISASSEMBLED OUPUT FROM COMPILER FAILS
! TO ASSEMBLE/BIND) is available from IBM Customer Support and from its
! <a href=" http://service.boulder.ibm.com/ ">service.boulder.ibm.com</a>
! website as PTF U453956.  This fix is incorporated in AIX 4.3.1 and above.
  
  <hr>
  <h2><a name="gdb">Problems debugging EGCS code</a></h2>
--- 976,989 ----
  </p>
  
  <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>
  <h2><a name="gdb">Problems debugging EGCS code</a></h2>
*************** the gdb-4.16 release may not be able to 
*** 782,797 ****
  a 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>
  <h2><a name="gnat">Using EGCS with GNAT/Ada </a></h2>
  <p>The GNU Ada front-end is not currently supported by EGCS; however, it is
  possible to build the GNAT compiler with a little work.
--- 994,999 ----
*************** out the latest snapshot.
*** 821,826 ****
--- 1023,1029 ----
  the form "egcs_ss_YYYYMMDD".  In addition, the latest official snapshot always
  has the tag "egcs_latest_snapshot".
  
+ 
  <hr>
  <h2><a name="picflag-needed">Why can't I build a shared library?</a></h2>
  <p>When building a shared library you may get an error message from the
*************** support PIC in this manner.  For example
*** 842,962 ****
  	gcc -shared -o libmyfile.so -fPIC myfile.o
  </pre>
  
- <hr>
- <h2><a name="sunos4ld">SunOS4 Linker core dumps</a></h2>
- <p>A bug in the SunOS4 linker will cause it to crash when linking -fPIC compiled
- objects.
- 
- <p>To fix this problem you can either use the most recent version of binutils or
- get the latest SunOS4 linker patch (patch ID 100170-10) from Sun's patch site.
- 
- <hr>
- <h2><a name="axparch">Assembler errors on Alpha targets</a></h2>
- 
- <p> Error: Unknown pseudo-op:  `.arch'
- <br>Linux/Alpha EV56 or PCA56 hosts running Red Hat 4.2 or 5.0 may see
- errors of this sort.  This is a signal that a new assembler is needed
- if you want to generate BWX insns for your machine.
- 
- <p>The version shipped with Red Hat 4.2 (2.7.0.2) has a fault wherein
- it will silently generate incorrect code.  The version shipped with
- Red Hat 5.0 (2.8.0.1) is not broken, but required an extra -m21164a
- argument on the command-line.  In order to visibly trap 2.7.0.2,
- I now issue DEC's .arch pseudo into the assembly.  Relieving the
- problem of mucking with command-line arguments for 2.8.0.1 is a
- pleasant side effect.
- 
- <p>If you've got Red Hat 5.0 installed, you may grab binutils 2.9.1
- and be happy.  If you've got Red Hat 4.2, bugs make it much harder
- to upgrade pieces on your own, and you are better off upgrading
- the entire system.
- 
- <p>In either case, your problem may be bypassed by not emitting BWX
- code by default.  Do this by using
- <pre>
- 	configure alphaev5-unknown-linux-gnulibc1
- </pre>
- if you have RH 4.2, or
- <pre>
- 	configure alphaev5-unknown-linux-gnu
- </pre>
- if you have RH 5.0.
- 
- <p> Error: macro requires $at register while noat in effect
- <br>This error also indicates that you should upgrade to a newer version of
- the assembler, 2.9 or later.  If you can not upgrade the assembler, the
- compiler option "-Wa,-m21164a" may work around this problem.
- 
- <hr>
- <h2><a name="sig11">Signal 11 on Linux</a></h2>
- <p> If you receive Signal 11 errors when building on Linux, then it is possible
- you have a hardware problem.  Further information on this can be found on
- <a href=" http://www.bitwizard.nl/sig11/ ">www.bitwizard.nl.</a>
- 
- 
- <hr>
- <h2><a name="bigtoc">Link failures using -bbigtoc on AIX 4.1</a></h2>
- <p>Some versions of the AIX binder (linker) can fail with a relocation
- overflow severe error when the -bbigtoc option is used to link
- GCC-produced object files into an executable that overflows the TOC.  A fix
- for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is
- available from IBM Customer Support and from its
- <a href=" http://service.boulder.ibm.com/ ">service.boulder.ibm.com</a>
- website as PTF U455193.
- 
- 
- <hr>
- <h2><a name="testoptions">How do I pass flags like
- <code>-fnew-abi</code> to the testsuite?</a></h2>
- <p>If you invoke <code>runtest</code> directly, you can use the
- <code>--tool_opts</code> option, e.g:
- <pre>
-   runtest --tool_opts "-fnew-abi -fno-honor-std" <other options>
- </pre>
- Or, if you use <code>make check</code> you can use the
- <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:
- <pre>
-   make RUNTESTFLAGS='--tool_opts "-fnew-abi -fno-honor-std"' check-g++
- </pre>
- 
- <hr>
- <h2><a name="o32abi">Does EGCS support the O32 ABI on IRIX 6</a></h2>
- <p>Gcc does not currently support generating O32 ABI binaries in the
- mips-sgi-irix6 configurations.
- 
- <p>It used to be possible to create a gcc with O32 ABI only support by
- configuring it for the mips-sgi-irix5 target.  See <a
- href="#irixlinks">below</a> for details.
- 
- <hr>
- <h2><a name="irix6n32bugs">Bugs in N32 and N64 ABI implementation on IRIX 6</a></h2>
- <p>Gcc does not correctly pass/return structures which are
- smaller than 16 bytes and which are not 8 bytes. The problem is very
- involved and difficult to fix. It affects a number of other targets also,
- but IRIX 6 is affected the most, because it is a 64 bit target, and 4 byte
- structures are common. The exact problem is that structures are being padded
- at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes
- of the register when it should be loaded into the upper 4 bytes of the
- register. 
- 
- <p>Gcc is consistent with itself, but not consistent with the SGI C compiler
- [and the SGI supplied runtime libraries], so the only failures that can
- happen are when there are library functions that take/return such
- structures. There are very few such library functions. I can only recall
- seeing two of them: inet_ntoa, and semctl. 
- 
- <hr>
- <h2><a name="aix43">Unable to bootstrap egcs-1.1 on AIX 4.3</a></h2>
- <p>The complete egcs-1.1 distribution will try to build 64-bit versions of
- all runtime libraries which will fail for libstdc++.  If only a C compiler is
- desired, configure and build egcs-core-1.1.  If other languages are needed,
- configure as if the system were rs6000-ibm-aix4.2, which will disable
- 64-bit support.  This will be fixed in the egcs-1.1.1 release.
- 
- <hr>
- <h2><a name="irixlinks">Links to other FAQs for GCC on IRIX platforms </a></h2>
- <p><a href=" http://reality.sgi.com/ariel/freeware/ "> 
- http://reality.sgi.com/ariel/freeware </a>
  
  <hr>
  <h2><a name="squangle">How to work around too long C++ symbol names? 
--- 1045,1050 ----
*************** have to rebuild them all again. :-(
*** 982,1040 ****
  initialized by default), then rebuilding egcs and any C++ libraries.
  
  <hr>
- <h2><a name="multipletests"> How can I run the test suite with multiple options? </a></h2>
- 
- <p>If you invoke <code>runtest</code> directly, you can use the
- <code>--target_board</code> option, e.g:
- <pre>
-   runtest --target_board "unix{-fPIC,-fpic,}" <other options>
- </pre>
- Or, if you use <code>make check</code> you can use the
- <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:
- <pre>
-   make RUNTESTFLAGS='--target_board "unix{-fPIC,-fpic,}"' check-gcc
- </pre>
- <p>Either of these examples will run the tests three times.   Once 
- with <code>-fPIC</code>, once with <code>-fpic</code>, and once with 
- no additional flags.
- <p>This technique is particularly useful on multilibbed targets.
- 
- <hr>
- <h2><a name="aixcoff">AIX 4.3 archive libraries ("not a COFF file")</a></h2>
- <p>AIX 4.3 utilizes a new "large format" archive to support both
- 32-bit and 64-bit object modules.  The routines provided in AIX 4.3.0 and
- AIX 4.3.1 to parse archive libraries did not handle the new format correctly.
- These routines are used by GCC and result in error messages during linking
- such as "not a COFF file".  The version of the routines shipped
- with AIX 4.3.1 should work for a 32-bit environment.  The <tt>-g</tt> option
- of the archive command may be used to create archives of 32-bit objects
- using the original "small format".  A correct version of the routines is
- shipped with AIX 4.3.2.
- 
- <hr>
- <h2><a name="next">Problems with EGCS on NEXTSTEP 3.x systems</a></h2>
- <p>On NEXTSTEP 3.x where x < 3 the build of egcs will abort during  
- stage1 with an error message like this:
- 
- <pre>
- _eh
- /usr/tmp/ccbbsZ0U.s:987:Unknown pseudo-op: .section
- /usr/tmp/ccbbsZ0U.s:987:Rest of line ignored. 1st junk character  
- valued 95 (_).
- </pre>
- 
- <p>The reason for this is the fact that NeXT's assembler for these  
- versions of the operating system does not support the .section  
- pseudo op that's needed for full C++ exception functionality.
- 
- As NeXT's assembler is a derived work from GNU as, a free  
- replacement that does can be obtained at 
- <a href=" ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz "> ftp://ftp.next.peak.org:/next-ftp/next/apps/devtools/as.3.3.NIHS.s.tar.gz </a>.
- 
- <hr>
  
  <p><a href="index.html">Return to the EGCS home page</a>
! <p><i>Last modified:  January  5, 1999</i>
  
  <!--#include virtual="/glimpsebox.html"-->
  </body>
--- 1070,1078 ----
  initialized by default), then rebuilding egcs and any C++ libraries.
  
  <hr>
  
  <p><a href="index.html">Return to the EGCS home page</a>
! <p><i>Last modified:  January  10, 1999</i>
  
  <!--#include virtual="/glimpsebox.html"-->
  </body>






More information about the Gcc-patches mailing list