File: faq.html

package info (click to toggle)
egcs 1.1.2-0slink2
links: PTS
area: main
in suites: slink
size: 80,844 kB
ctags: 90,426
sloc: ansic: 675,911; cpp: 103,606; sh: 26,374; pascal: 22,878; yacc: 13,856; asm: 10,896; makefile: 8,137; lisp: 7,252; exp: 3,490; fortran: 1,519; sed: 587; objc: 482; awk: 223; csh: 106; ml: 94; perl: 18
file content (1118 lines) | stat: -rw-r--r-- 48,246 bytes
parent folder | download | duplicates (2)
<html>
<head>
<title>EGCS Frequently Asked Questions</title>
</head>
<body>

<h1 align="center">EGCS Frequently Asked Questions</h1>

The latest version of this document is always available at <a href="
http://egcs.cygnus.com/faq.html">http://egcs.cygnus.com/faq.html</a>.

<p>This FAQ tries to answer specific questions concerning EGCS. For
general information regarding C resp. C++, please check the 
<a href="http://www.eskimo.com/~scs/C-faq/top.html">comp.lang.c FAQ</a>,
<a href="http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/">
comp.lang.c++ FAQ</a>, and the
<a href="http://reality.sgi.com/austern_mti/std-c++/faq.html">
comp.std.c++ FAQ</a>.

<hr>

<h1>Questions</h1>
<ol>
  <li><a href="#general">General information</a>
  <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> 

  <li><a href="#installation">Installation</a>
  <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>

  <li><a href="#testsuite">Testsuite problems</a>
  <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>

  <li><a href="#platform">Platform-specific issues</a>
  <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">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 GNU/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="#aixld">Linker error on AIX 4.3.2</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>

  <li><a href="#bugs">Bugs and Non-Bugs</a>
  <ol>
    <li><a href="#fdzero">FD_ZERO macro</a>
    <li><a href="#octave">Octave 2.0.13 does not compile</a>
  </ol>

  <li><a href="#misc">Miscellaneous</a>
  <ol>
    <li><a href="#memexhausted">Virtual memory exhausted</a>
    <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>
    <li><a href="#gperf">When building from CVS sources, I see 'gperf: invalid option -- F', 
	even with the most current version of gperf.</a>
  </ol>
</ol>


<hr>
<a name="general"></a>
<h1>General information</h1>

<h2><a name="gcc-2-diff">How is EGCS 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 reexamination of basic architectural decisions of
    gcc and an interest in adding new optimizations;

  <li>working with the groups who have fractured out from gcc2 (like
   the Linux kernel 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 want 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 integrated--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 the Linux kernel 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="bugreport">How to report bugs</a></h2>
<p>There are complete instructions in the egcs info manual, section Bugs.  The
manual can be read using `<i>M-x <tt>info</tt></i>' in Emacs, or if the GNU
<tt>info</tt> program is installed on your system by
 `<tt>info --node "(gcc)Bugs"</tt>'.
Or see the file <a href="/cgi-bin/cvsweb/gcc/BUGS?rev=1.1">BUGS</a> included
with the egcs source code.

<p>Before you report a bug for the <em>C++ compiler</em>, please check
the <a href="bugs.html">list of well-known bugs</a>. If you
want to report a bug with <em>egcs 1.0.x</em>, we recommend upgrading
to the current release first.

<p>In short, if egcs says <tt>Internal compiler error</tt> (or any
other error that you'd like us to be able to reproduce, for that
matter), please mail a bug report to <a
href="mailto:egcs-bugs@egcs.cygnus.com">egcs-bugs@egcs.cygnus.com</a> including:

<ul>
  <li>The egcs version

  <li>The system type

  <li>All options you passed to egcs

  <li>Preprocessed output of the source file that caused the compiler error
</ul>

<p>All this can normally be accomplished by mailing the command line, the
output of the command, and the resulting `<tt><i>your-file</i>.i</tt>' for C,
or `<tt><i>your-file</i>.ii</tt>' for C++, corresponding to:

<p><tt>gcc -v --save-temps <i>all-your-options</i> <i>your-file</i>.c</tt>

<p>Typically the CPP output will be large, so please compress the resulting
file with one of the popular compression programs such as <tt>gzip</tt>,
<tt>bzip2</tt>, <tt>compress</tt> or <tt>pkzip</tt>, then include the
compressed CPP output as an attachment to your message.

<p>The egcs lists have message size limits (100 kbytes) and bug reports
over those limits will currently be bounced.  We're trying to find a
way to allow larger bug reports to be posted, but this is currently
impossible.  So, although we prefer to have complete bug reports
archived, if you cannot reduce the bug report below the limit, please
make it available for ftp or http and post the URL.


<hr>
<a name="installation"></a>
<h1>Installation</h1>

<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 GNU/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 GNU/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="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.

<p>An alternative to using symlinks is to configure with a
--program-transform-name option. This option specifies a sed command to
process installed program names with. Using it you can, for instance,
have all the EGCS programs installed as "egcs-gcc" and the like. You
will still have to specify different --prefix options for EGCS and
gcc2, because it is only the executable program names that are
transformed. The difference is that you (as administrator) do not have
to set up symlinks, but must specify additional directories in your (as
a user) PATH. A complication with --program-transform-name is that the
sed command invariably contains characters significant to the shell,
and these have to be escaped correctly, also it is not possible to use
"^" or "$" in the command. Here is the option to prefix "egcs-" to the
egcs installed programs
"--program-transform-name='s,\\\\(.*\\\\),egcs-\\\\1,'". With the above
--prefix option, that will install the EGCS programs into
/usr/local/egcs/bin with names prefixed by "egcs-". You can use
--program-transform-name if you have multiple versions of EGCS, and
wish to be sure about which version you are invoking.

<p>If you use --prefix, EGCS may have difficulty locating a GNU
assembler or linker on your system, <a href="#gas">GCC can not find GNU
as/GNU ld</a> explains how to deal with this.

<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>

<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" &lt;other options&gt;
</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,}" &lt;other options&gt;
</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>

<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 yet
supported on this platform.

<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.  Releases of binutils prior to 2.9 are known to
assemble exception handling code incorrectly.

<p>We recommend binutils-2.9.1 or newer.  Some post-2.9.1 snapshots of
binutils fix some subtle bugs, particularly on x86 and alpha.  They
are available at <a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/">
ftp://tsx-11.mit.edu/pub/linux/packages/GCC/</A>.  The 2.9.1.0.15
snapshot is known to work fine on those platforms; other than that, be
aware that snapshots are in general untested and may not work (or even
build).  Use them at your own risk.

<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.
Instead, it could spuriously and silently generate incorrect code for
certain non-obvious cases of source code.  Even more unfortunately, the
manual (Using and Porting GCC, section Extended Asm, see the
<a href="#bugreport"> bug report entry</a>) did not explicitly say that it
was invalid to specify clobber registers that were destined to overlap
operands; it could arguably be interpreted that it was correct to clobber
an input operand to mark it as not holding a usable value after the asm.

<p>For the general case, there is no way to tell whether a specified
clobber is <i>intended</i> to overlap with a specific (input) operand or
is a program error, where the choice of actual register for operands
failed to <i>avoid</i> the clobbered register.  Such unavoidable overlap
is detected by versions egcs-2.92.18 19981104 and above, and flagged
as an error rather than accepted.  An error message is given, such as:
<pre>
foo.c: In function `foo':
foo.c:7: Invalid `asm' statement:
foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG.
</pre>
Unfortunately, a lot of existing software, for example the
<a href="#linuxkernel">Linux kernel</a> version 2.0.35 for the Intel x86,
has constructs where input operands are marked as clobbered.

<p>The manual now describes how to write constructs with operands that
are modified by the construct, but not actually used.  To write an asm
which modifies an input operand but does not output anything usable,
specify that operand as an <b>output operand</b> outputting to an
<b>unused dummy variable</b>.

<p>In the following example for the x86 architecture (taken from the Linux
2.0.35 kernel -- <tt>include/asm-i386/delay.h</tt>), the register-class
constraint <tt>"a"</tt> denotes a register class containing the single
register <tt>"ax"</tt> (aka. <tt>"eax"</tt>).  It is therefore invalid
to clobber <tt>"ax"</tt>; this operand has to be specified as an output
as well as an input.  The following code is therefore <b>invalid</b>:
<pre>
extern __inline__ void
__delay (int loops)
{
  __asm__ __volatile__
    (".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
     : /* no outputs */
     : "a" (loops)
     : "ax");
}
</pre>
It could be argued that since the register class for <tt>"a"</tt> contains
only a single register, this could be detected as an "obvious" intended
clobber of the input operand.  While that is feasible, it opens up for
further "obvious" cases, where the level of obviousness changes from
person to person.  As there is a correct way to write such asm constructs,
this obviousness-detection is not needed other than for reasons of
compatibility with an existing code-base, and that code base can be
corrected.
<p>
This corrected and clobber-less version, is <b>valid</b> for egcs of
current CVS, as well as for previous versions of gcc:
<pre>
extern __inline__ void
__delay (int loops)
{
  int dummy;

  __asm__ __volatile__
    (".align 2,0x90\n1:\tdecl %0\n\tjns 1b"
     : "=a" (dummy)
     : "0" (loops));
}
</pre>
Note that the asm construct now has an output operand, but it is unused.
Normally asm constructs with only unused output operands may be removed by
gcc, unless marked <tt>volatile</tt> as above.


<hr>
<h2><a name="hpcompare">Bootstrap comparison failures on HPs</a></h2>
<p>If you bootstrap the compiler on HP-UX 10.x using the HP assembler instead 
of gas, every file will fail the comparison test.  Please see the section on 
HP-UX 10.x in the <a href = "install/specific.html">Host/Target specific 
installation notes</a> for more information

<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>It has been reported that this is a known bug in the make shipped with
IRIX 5.2.  We recommend you use GNU make instead of the vendor supplied
make program; however, you may have success with "smake" on IRIX 5.2 if
you do not have GNU make available.

<hr>
<h2><a name="linuxkernel">Building Linux kernels</a></h2>
<p>Linux 2.2.x kernels work with any version of egcs.

<p>If you try to build a 2.0.x kernel for Intel machines with egcs,
then you are on your own.  The 2.0.x kernels are to be built only with
gcc 2.7.2.  They use certain <code>asm</code> constructs which are
incorrect, but (by accident) happen to work with gcc 2.7.2.  If you
insist on building 2.0.x kernels with egcs, you may be interested in
this <a href="http://www.suse.de/~florian/kernel+egcs.html">patch</a>
which fixes some of the asm problems.  You will also want to change
asm constructs to <a href="#asmclobber">avoid clobbering their input
operands</a>.

<p>If you installed a recent binutils/gas snapshot on your GNU/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.  (This 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.)

<p>Finally, you may get errors with the X driver of the form 
<pre>
_X11TransSocketUNIXConnect: Can't connect: errno = 111
</pre>

<p>This is 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="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++</a></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>GNU/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 GNU/Linux</a></h2>
<p>If you receive Signal 11 errors when building on GNU/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 &quot;large format&quot; 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 &quot;not a COFF file&quot;.  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="aixld">Linker error on AIX 4.3.2</a></h2>
<p>The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core
with a segmentation fault when invoked by any version of GCC.  A fix for
APAR IX87327 will be available from IBM Customer Support.

<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 some versions of NEXTSTEP 3.x, compilation of EGCS will fail during
stage1.  More information can be found in the section on NEXTSTEP 3.x in the 
<a href = "install/specific.html">Host/Target specific installation notes</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 &lt;file&gt;.new to be changed to &lt;file&gt;-new.


<hr>
<a name="bugs"></a>
<h1>Bugs and Non-Bugs</h1>

<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:

<p>There is a separate <a href="bugs.html">list of well-known bugs</a>
describing known deficiencies. Naturally we'd like that list to be of
zero length.

<p>To report a bug, see <a href="#bugreport">How to report bugs</a>.

<hr>
<h2><a name="fdzero">FD_ZERO macro</a></h2>

<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 &lt;drepper@cygnus.com&gt; 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)]), \
			    "=&amp;c" (__d0), "=&amp;D" (__d1) \
			  : "a" (0), "1" (sizeof (__fd_set) \
					  / sizeof (__fd_mask)), \
			    "2" ((__fd_mask *) (fdsetp)) \
			  : "memory"); \
    } while (0)
</PRE>

<hr>
<h2><a name="octave">Octave 2.0.13 does not compile</a></h2>

<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.


<hr>
<a name="misc"></a>  
<h1>Miscellaneous</h1>

<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="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>
<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.
Here's an example:

<p><pre>
template &lt;typename T&gt; class foo {
  friend void bar(foo&lt;T&gt;);
}
</pre>

<p>The above declaration declares a non-template function named
<TT>bar</TT>, so it must be explicitly defined for <B>each</B>
specialization of <TT>foo</TT>.  A template definition of <TT>bar</TT>
won't do, because it is unrelated with the non-template declaration
above.  So you'd have to end up writing:

<p><pre>
void bar(foo&lt;int&gt;) { /* ... */ }
void bar(foo&lt;void&gt;) { /* ... */ }
</pre>

<p>If you meant <TT>bar</TT> to be a template function, you should
have forward-declared it as follows.  Note that, since the template
function declaration refers to the template class, the template class
must be forward-declared too:

<p><pre>
template &lt;typename T&gt;
class foo;

template &lt;typename T&gt;
void bar(foo&lt;T&gt;);

template &lt;typename T&gt;
class foo {
  friend void bar&lt;&gt;(foo&lt;T&gt;);
};

template &lt;typename T&gt;
void bar(foo&lt;T&gt;) { /* ... */ }
</pre>

<p>In this case, the template argument list could be left empty,
because it can be implicitly deduced from the function arguments, but
the angle brackets must be present, otherwise the declaration will be
taken as a non-template function.  Furthermore, in some cases, you may
have to explicitly specify the template arguments, to remove
ambiguity.

<p>An error in the last public comment draft of the ANSI/ISO C++
Standard and the fact that previous releases of gcc would accept such
friend declarations as template declarations has led people to believe
that the forward declaration was not necessary, but, according to the
final version of the Standard, it is.

<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++ release that works with
EGCS from <a
href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/">ftp://egcs.cygnus.com/pub/egcs/infrastructure/</a>.
Note that the 2.8.2 snapshot pre-dates the 2.8.1.2 release.

<hr>
<h2><a name="generated_files">autoconf, bison, xgettext, automake, etc</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 several additional programs
to build EGCS.

<p>These include, but are not necessarily limited to autoconf, automake,
bison, and xgettext.

<p>This is necessary because neither diff nor cvs keep timestamps
correct.  This causes problems for generated files as "make" may think
those generated files are out of date and try to regenerate them.

<p>An easy way to work around this problem is to use the egcs_update
script in the contrib subdirectory of egcs, which handles this
transparently without requiring installation of any additional tools.</p>


<p>When building from diffs or CVS or if you modified some sources,
you may also need to obtain development versions of some GNU tools, as
the production versions do not necessarily handle all features needed
to rebuild egcs.</p>

<p>Autoconf is available from
<a href="http://sourceware.cygnus.com/autoconf/">
http://sourceware.cygnus.com/autoconf/</a>; have a look at
<a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure/">
ftp://egcs.cygnus.com/pub/egcs/infrastructure/</a> for the other packages.
</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>
<p>On some systems EGCS will produce dwarf debug records by default; however
the 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
a copy of gdb-4.17 to work around the problem.

<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.

<p>First, retrieve the gnat-3.10p sources.  The sources for the Ada front
end and runtime all live in the "ada" subdirectory.  Move that subdirectory
to egcs/gcc/ada.

<p>Second, apply the patch found in egcs/gcc/README.gnat.

<p>Finally, rebuild per the GNAT build instructions.

<hr>
<h2><a name="gpc">Using EGCS with GNU Pascal</a></h2>
<p>The <a href="http://home.pages.de/~GNU-Pascal/">GNU Pascal</a>
front-end does work with egcs-1.1 It does not work with egcs-1.0.x and
the main branch as of egcs-2.92.18. A tarball can be found at
<A HREF="ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/">
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/</A>.

<hr>
<h2><a name="cvssnapshots">Using CVS to download snapshots</a></h2>
<p>It is possible to checkout specific snapshots with CVS or to check
out the latest snapshot.

<p>We use CVS tags to identify each snapshot we make.  Snapshot tags have
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
linker like `assert pure-text failed:' or `DP relative code in file'.

<p>This kind of error occurs when you've failed to provide proper flags
to gcc when linking the shared library. 

<p>You can get this error even if all the .o files for the shared library were
compiled with the proper PIC option.  When building a shared library, gcc will
compile additional code to be included in the library.  That additional code
must also be compiled with the proper PIC option.

<p>Adding the proper PIC option (<tt>-fpic</tt> or <tt>-fPIC</tt>) to the link
line which creates the shared library will fix this problem on targets that
support PIC in this manner.  For example:
<pre>
	gcc -c -fPIC myfile.c
	gcc -shared -o libmyfile.so -fPIC myfile.o
</pre>


<hr>
<h2><a name="squangle">How to work around too long C++ symbol names? 
(<tt>-fsquangle</tt>)</a></h2>

<p>If the standard assembler of your platform can't cope with the
large symbol names that the default g++ name mangling mechanism
produces, your best bet is to use GNU as, from the GNU binutils
package.

<p>Unfortunately, GNU as does not support all platforms supported by
egcs, so you may have to use an experimental work-around: the
<tt>-fsquangle</tt> option, that enables compression of symbol names.

<p>Note that this option is still under development, and subject to
change.  Since it modifies the name mangling mechanism, you'll need to
build libstdc++ and any other C++ libraries with this option enabled.
Furthermore, if this option changes its behavior in the future, you'll
have to rebuild them all again. :-(

<p>This option can be enabled by default by initializing
`flag_do_squangling' with `1' in `gcc/cp/decl2.c' (it is not
initialized by default), then rebuilding egcs and any C++ libraries.

<hr>

<h2><a name="gperf">When building from CVS sources, I see 'gperf: 
invalid option -- F', even with the most current version of gperf.
</a></h2>

<p>The current version of gperf (v2.7) does not support the -F flag 
which is used when building egcs from CVS sources.  You will need to 
obtain a patch for gperf and rebuild the program; this patch is available 
at <a href="ftp://egcs.cygnus.com/pub/egcs/infrastructure">
ftp://egcs.cygnus.com/pub/egcs/infrastructure/</a>

<p>Patches for other tools, particularly autoconf, may also be necessary 
if you're building from CVS sources.  Please see the 
<a href="#generated_files">FAQ entry</a> regarding these tools to 
determine if anything else is needed.

<p>These patched utilities should <strong>only</strong> be required if 
you are building from CVS sources.  For example, gperf is used to 
generate C code for a perfect hash function given an input file.  
Distributions of egcs already contain the generated C code, while the 
CVS sources will provide only the gperf input file.  So gperf should 
only be necessary if you are building anything obtained from CVS.

<hr>


<p><a href="index.html">Return to the EGCS home page</a>
<p><i>Last modified:  March 10, 1999</i>

<!--#include virtual="/glimpsebox.html"-->
</body>
</html>