INSTALL/faq.html

   1 <html>
   2 <head>
   3 <title>egcs Frequently Asked Questions</title>
   4 </head>
   5 <body bgcolor="white">
   6 <h1 align="center">egcs Frequently Asked Questions</h1>
   7
   8 <ol>
   9   <li><a href="#gcc-2-diff">How is egcs be different from gcc2?</a>
  10   <li><a href="#open-development">What is an open development model?</a>
  11   <li><a href="#release-fork">Releases and Forking</a>
  12   <li><a href="#libc-lock">bits/libc-lock.h:  No such file or directory</a>
  13   <li><a href="#morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a>
  14   <li><a href="#fortran">Problems building the Fortran compiler</a>
  15   <li><a href="#mips">Problems building on MIPS platforms</a>
  16   <li><a href="#x86eh">Problems with exception handling on x86 platforms</a>
  17   <li><a href="#hpcompare">Bootstrap comparison failures on HPs</a>
  18   <li><a href="#makebugs">Bootstrap loops rebuilding cc1 over and over</a>
  19   <li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a>
  20   <li><a href="#rpath">libstdc++/libio tests fail badly with --enable-shared</a>
  21   <li><a href="#dejagnu">Unable to run the testsuite</a>
  22   <li><a href="#cross">How to build a cross compiler</a>
  23   <li><a href="#multiple">How to install both gcc2 and egcs</a>
  24   <li><a href="#snapshot">Snapshots, how, when, why</a>
  25   <li><a href="#linuxkernel">Problems building Linux kernels</a>
  26   <li><a href="#memexhausted">Virtual memory exhausted</a>
  27   <li><a href="#gas">GCC can not find GAS</a>
  28   <li><a href="#rh5.0">egcs does not work on Red Hat 5.0</a>
  29   <li><a href="#x86solaris">Unable to bootstrap on x86 Solaris2.{5,6}</a>
  30   <li><a href="#windows">EGCS with Windows</a>
  31   <li><a href="#environ">cpp: Usage:... Error<a>
  32   <li><a href="#kde">EGCS will not build KDE<a>
  33
  34 </ol>
  35
  36 <hr>
  37 <h2><a name="gcc-2-diff">How is egcs be different from gcc2?</a></h2>
  38
  39 <p>Six years ago, gcc version 1 had reached a point of stability.  For the
  40 targets it could support, it worked well.  It had limitations inherent in
  41 its design that would be difficult to resolve, so a major effort was made
  42 and gcc version 2 was the result.  When we had gcc2 in a useful state,
  43 development efforts on gcc1 stopped and we all concentrated on making
  44 gcc2 better than gcc1 could ever be.  This is the kind of step forward
  45 we want to make with egcs.
  46
  47 <p>In brief, the three biggest differences between egcs and gcc2 are
  48 these:
  49
  50 <ul>
  51   <li>More rexamination of basic architectual decisions of
  52     gcc and an interest in adding new optimizations;
  53
  54   <li>working with the groups who have fractured out from gcc2 (like
  55    the Linux folks, the Intel optimizations folks, Fortran folks)
  56    including more front-ends; and finally
  57
  58   <li>An open development model (<a
  59    href="#open-development">see below</a>) for the development process.
  60 </ul>
  61
  62 <p>These three differences will work together to result in a more
  63 useful compiler, a more stable compiler, a central compiler that works
  64 for more people, a compiler that generates better code.
  65
  66
  67 <p>There are a lot of exciting compiler optimizations that have come
  68 out.  We want them in gcc.  There are a lot of front ends out there for
  69 gcc for languages like Fortran or Pascal.  We want them easily
  70 installable by users.  After six years of working on gcc2, we've come
  71 to see problems and limitations in the way gcc is architected; it is
  72 time to address these again.
  73
  74 <hr>
  75 <h2><a name="open-development">What is an open development model?</a></h2>
  76
  77 <p>With egcs, we are going to try a bazaar style<a
  78 href="#cathedral-vs-bazaar"><b>[1]</b></a> approach to its
  79 development:  We're going to be making snapshots publicly available
  80 to anyone who wants to try them; we're going to welcome anyone to join
  81 the development mailing list.  All of the discussions on the
  82 development mailing list are available via the web.  We're going to be
  83 making releases with a much higher frequency than they have been made
  84 in the past:  We're shooting for three by the end of 1997.
  85
  86 <p>In addition to weekly snapshots of the egcs development sources, we
  87 are going to look at making the sources readable from a CVS server by
  88 anyone.  We want to make it so external maintainers of parts of egcs
  89 are able to commit changes to their part of egcs directly into the
  90 sources without going through an intermediary.
  91
  92 <p>There have been many potential gcc developers who were not able to
  93 participate in gcc development in the past.  We these people to help in
  94 any way they can; we ultimately want gcc to be the best compiler in the
  95 world.
  96
  97 <p>A compiler is a complicated piece of software, there will still be
  98 strong central maintainers who will reject patches, who will demand
  99 documentation of implementations, and who will keep the level of
 100 quality as high as it is today.  Code that could use wider testing may
 101 be intergrated--code that is simply ill-conceived won't be.
 102
 103 <p>egcs is not the first piece of software to use this open development
 104 process; FreeBSD, the Emacs lisp repository, and Linux are a few
 105 examples of the bazaar style of development.
 106
 107 <p>With egcs, we will be adding new features and optimizations at a
 108 rate that has not been done since the creation of gcc2; these additions
 109 will inevitably have a temporarily destabilizing effect.  With the help
 110 of developers working together with this bazaar style development, the
 111 resulting stability and quality levels will be better than we've had
 112 before.
 113
 114 <blockquote>
 115 <a name="cathedral-vs-bazaar"><b>[1]</b></a>
 116   We've been discussing different development models a lot over the
 117   past few months.  The paper which started all of this introduced two
 118   terms:  A <b>cathedral</b> development model versus a <b>bazaar</b>
 119   development model.  The paper is written by Eric S. Raymond, it is
 120   called ``<a
 121   href="http://locke.ccil.org/~esr/writings/cathedral.html">The
 122   Cathedral and the Bazaar</a>''.  The paper is a useful starting point
 123   for discussions.
 124 </blockquote>
 125
 126 <hr>
 127 <h2><a name="release-fork">Releases and Forking?</a></h2>
 128 <p>Some folks have questioned whether or not making releases is consistent
 129 with the goals of the egcs project and whether or not making releases is
 130 a fork from gcc2.
 131
 132 <pre>
 133 The egcs project has several goals, including:
 134
 135   * Experimenting with a new development model, release process and
 136   release packaging,
 137
 138   * Using the new development model to accelerate development of new
 139   features, optimizations, etc for future inclusion in gcc,
 140
 141   * Providing high quality releases to the public.
 142
 143 An egcs release is a copy of the egcs sources that the developers have
 144 tested and are believed to be suitable for wider scale use and testing.
 145
 146 Making releases of stable, tested sources is both a goal and a means by
 147 which we hope to achieve other goals of the egcs project.
 148
 149 The existence of a stable tested release allows egcs to be more thoroughly
 150 used and tested by a wider audience than is capable of testing snapshots.
 151 The expanded audience provides developers with critical feedback in a
 152 timely manner, which is beneficial to GCC as a whole and is consistent with
 153 the stated goals of egcs.
 154
 155 The gcc maintainers are encouraged to migrate tested fixes and new features
 156 from egcs into gcc at their discretion.  egcs maintainers are willing to
 157 assist the gcc maintainers as time permits.  egcs periodically merges in
 158 changes from gcc into the egcs sources.
 159
 160 What will keep egcs from becoming a fork is cooperation between the
 161 developers of gcc and egcs.
 162
 163 We don't see this situation as significantly different than other projects
 164 that make releases based on some version of the gcc sources (Cygnus, g77,
 165 etc).  All the code is still available for inclusion in gcc at the discretion
 166 of the gcc maintainers.
 167 </pre>
 168
 169 <hr>
 170 <h2><a name="libc-lock">bits/libc-lock.h: No such file or directory</a></h2>
 171 <p>This entry should be obsolete, egcs should handle these beta versions of
 172 glibc2 correctly.
 173
 174 <p>egcs includes a tightly integrated libio and libstdc++ implementation which
 175 can cause problems on hosts which have libio integrated into their C library
 176 (most notably Linux).
 177
 178 <p>We believe that we've solved the major technical problems for the most
 179 common versions of libc found on Linux systems.  However, some versions
 180 of Linux use pre-release versions of glibc2, which egcs has trouble detecting
 181 and correctly handling.
 182
 183 <p>If you're using one of these pre-release versions of glibc2, you may get
 184 a message "bits/libc-lock.h: No such file or directory" when building egcs.
 185 Unfortunately, to fix this problem you will need to update your C library to
 186 glibc2.0.5c.
 187
 188 <hr>
 189 <h2><a name="morelibc">`_IO_stdfile_0_lock' was not declared in this scope</a></h2>
 190 <p>If you get this error, it means either egcs incorrectly guessed what version
 191 of libc is installed on your linux system, or you incorrectly specified a
 192 version of glibc when configuring egcs.
 193
 194 <p>If you did not provide a target name when configuring egcs, then you've
 195 found a bug which needs to be reported.  If you did provide a target name at
 196 configure time, then you should reconfigure without specifying a target name.
 197
 198 <hr>
 199 <h2><a name="fortran">Problems building the Fortran compiler</a></h2>
 200 <p>The Fortran front end can not be built with most vendor compilers; it must
 201 be built with gcc.  As a result, you may get an error if you do not follow
 202 the install instructions carefully.
 203
 204 <p>In particular, instead of using "make" to build egcs, you should use
 205 "make bootstrap" if you are building a native compiler or "make cross"
 206 if you are building a cross compiler.
 207
 208 <p>It has also been reported that the Fortran compiler can not be built
 209 on Red Hat 4.X linux for the Alpha.  Fixing this may require upgrading
 210 binutils or to Red Hat 5.0; we'll provide more information as it becomes
 211 available.
 212
 213 <hr>
 214 <h2><a name="mips">Problems building on MIPS platforms</a></h2>
 215 <p>egcs requires the use of GAS on all versions of Irix, except Irix 6 due
 216 to limitations in older Irix assemblers.
 217
 218 <p> Either of these messages indicates that you are using the MIPS assembler
 219 when instead you should be using GAS.
 220
 221 <pre>
 222     as0: Error: ./libgcc2.c, line 1:Badly delimited numeric literal
 223           .4byte $LECIE1-$LSCIE1
 224     as0: Error: ./libgcc2.c, line 1:malformed statement
 225 </pre>
 226
 227 <hr>
 228 <pre>
 229     as0: Error: /home/law/egcs_release/gcc/libgcc2.c, line 1:undefined symbol in expression
 230     .word $LECIE1-$LSCIE1
 231
 232 </pre>
 233
 234
 235 <p> For Irix 6, you should use the native assembler as GAS is not supported
 236 on Irix 6.
 237
 238 <hr>
 239 <h2> <a name="x86eh">Problems with exception handling on x86 platforms</a></h2>
 240 <p>If you are using the GNU assembler (aka gas) on an x86 platform and
 241 exception handling is not working correctly, then odds are you're using a
 242 buggy assembler.
 243
 244 <p>We recommend binutils-2.8.1.0.15 or newer.
 245 <br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.tar.gz"> binutils-2.8.1.0.15 source</a>
 246 <br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.bin.tar.gz"> binutils-2.8.1.0.15 x86 binary for libc5</a>
 247 <br><a href="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/binutils-2.8.1.0.15.glibc.bin.tar.gz"> binutils-2.8.1.0.15 x86 binary for glibc2</a>
 248 Or, you can try a
 249 <a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/gas-970915.tar.gz"> binutils snapshot</a>; however, be aware that the binutils snapshot is untested
 250 and may not work (or even build).  Use it at your own risk.
 251
 252 <hr>
 253 <h2> <a name="hpcompare">Bootstrap comparison failures on HPs</a></h2>
 254 <p>If you bootstrap the compiler on hpux10 using the HP assembler instead of
 255 gas, every file will fail the comparison test.
 256
 257 <p>The HP asembler inserts timestamps into object files it creates, causing
 258 every file to be different.  The location of the timestamp varies for each
 259 object file, so there's no real way to work around this mis-feature.
 260
 261 <p>Odds are your compiler is fine, but there's no way to be certain.
 262
 263 <p>If you use GAS on HPs, then you will not run into this problem because
 264 GAS never inserts timestamps into object files.  For this and various other
 265 reasons we highly recommend using GAS on HPs.
 266
 267 <hr>
 268 <h2> <a name="makebugs">Bootstrap loops rebuilding cc1 over and over</a></h2>
 269 <p>When building egcs, the build process loops rebuilding cc1 over and
 270 over again.  This happens on mips-sgi-irix5.2, and possibly other platforms.
 271
 272 <p>This is probably a bug somewhere in the egcs Makefile.  Until we find and
 273 fix this bug we recommend you use GNU make instead of vendor supplied make
 274 programs.
 275
 276 <hr>
 277 <h2> <a name="rpath">Dynamic linker is unable to find GCC libraries</a></h2>
 278 <p>This problem manifests itself by programs not finding shared libraries
 279 they depend on when the programs are started.  Note this problem often manifests
 280 itself with failures in the libio/libstdc++ tests after configuring with
 281 --enable-shared and building egcs.
 282
 283 <p>GCC does not specify a runpath so that the dynamic linker can find dynamic
 284 libraries at runtime.
 285
 286 <p>The short explaination is that if you always pass a -R option to the
 287 linker, then your programs become dependent on directories which
 288 may be NFS mounted, and programs may hang unnecessarily when an
 289 NFS server goes down.
 290
 291 <p>The problem is not programs that do require the directories; those
 292 programs are going to hang no matter what you do.  The problem is
 293 programs that do not require the directories.
 294
 295 <p>SunOS effectively always passed a -R option for every -L option;
 296 this was a bad idea, and so it was removed for Solaris.  We should
 297 not recreate it.
 298
 299 <hr>
 300 <h2> <a name="dejagnu">Unable to run the testsuite</a></h2>
 301 <p>If you get a message about unable to find "standard.exp" when trying to
 302 run the egcs testsuites, then your dejagnu is too old to run the egcs tests.
 303 You will need to get a newer version of dejagnu; we've made a
 304 <a href="ftp://ftp.cygnus.com/pub/egcs/infrastructure/dejagnu-971222.tar.gz">
 305 dejagnu snapshot</a> available until a new version of dejagnu can be released.
 306
 307 <hr>
 308 <h2> <a name="cross">How to build a cross compiler</a></h2>
 309 <p> Building cross compilers is a rather complex undertaking because they
 310 usually need additional software (cross assembler, cross linker, target
 311 libraries, target include files, etc).
 312
 313 <p> We recommend reading the <a href="ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ-0.8.1">
 314 crossgcc FAQ</a> for information about building cross compilers.
 315
 316 <p> If you have all the pieces available, then `make cross' should build a
 317 cross compiler.  `make LANGUAGES="c c++" install'will install the cross
 318 compiler.
 319
 320 <p> Note that if you're trying to build a cross compiler in a tree which
 321 includes binutils-2.8 in addition to egcs, then you're going to need to
 322 make a couple minor tweaks so that the cross assembler, linker and
 323 nm utilities will be found.
 324
 325 <p>binutils-2.8 builds those files as gas.new, ld.new and nm.new; egcs gcc
 326 looks for them using gas-new, ld-new and nm-new, so you may have to arrange
 327 for any symlinks which point to &ltfile&gt.new to be changed to &ltfile&gt-new.
 328
 329 <hr>
 330 <h2> <a name="snapshot">Snapshots, how, when, why</a></h2>
 331 <p> We make snapshots of the egcs sources about once a week; there is no
 332 predetermined schedule.  These snapshots are intended to give everyone
 333 access to work in progress.  Any given snapshot may generate incorrect code
 334 or even fail to build.
 335
 336 <p>If you plan on downloading and using snapshots, we highly recommend you
 337 subscribe to the egcs mailing lists.  See <a href="index.html#mailinglists">
 338 mailing lists</a> on the main egcs page for instructions on how to subscribe.
 339
 340 <p>When using the diff files to update from older snapshots to newer snapshots,
 341 make sure to use "-E" and "-p" arguments to patch so that empty files are
 342 deleted and full pathnames are provided to patch.  If your version of
 343 patch does not support "-E", you'll need to get a newer version.  Also note
 344 that you may need autoconf, autoheader and various other programs if you use
 345 diff files to update from one snapshot to the next.
 346
 347 <hr>
 348 <h2> <a name="multiple">How to install both egcs and gcc2</a></h2>
 349 <p>It may be desirable to install both egcs and gcc2 on the same system.  This
 350 can be done by using different prefix paths at configure time and a few
 351 symlinks.
 352
 353 <p>Basically, configure the two compilers with different --prefix options,
 354 then build and install each compiler.  Assume you want "gcc" to be the egcs
 355 compiler and available in /usr/local/bin; also assume that you want "gcc2"
 356 to be the gcc2 compiler and also available in /usr/local/bin.
 357
 358 <p>The easiest way to do this is to configure egcs with --prefix=/usr/local/egcs
 359 and gcc2 with --prefix=/usr/local/gcc2.  Build and install both compilers.
 360 Then make a symlink from /usr/local/bin/gcc to /usr/local/egcs/bin/gcc and
 361 from /usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc.  Create similar links
 362 for the "g++", "c++" and "g77" compiler drivers.
 363
 364 <hr>
 365 <h2> <a name="linuxkernel">Problems building Linux kernels</a></h2>
 366 <p>If you installed a recent binutils/gas snapshot on your Linux system,
 367 you may not be able to build the kernel because objdump does not understand
 368 the "-k" switch.  The solution for this problem is to remove /usr/bin/encaps.
 369
 370 <p>The reason you must remove /usr/bin/encaps is because it is an obsolete
 371 program that was part of older binutils distributions; the Linux kernel's
 372 Makefile looks for this program to decide if you have an old or a new
 373 binutils.  Problems occur if you installed a new binutils but haven't
 374 removed encaps, because the Makefile thinks you have the old one.  So zap
 375 it; trust us, you won't miss it.
 376
 377 <p>You may get an internal compiler error compiling process.c in newer
 378 versions of the Linux kernel on x86 machines.  This is a bug in an asm
 379 statement in process.c, not a bug in egcs.  XXX How to fix?!?
 380
 381 <p>You may get errors with the X driver of the form
 382 <pre>
 383 _X11TransSocketUNIXConnect: Can't connect: errno = 111
 384 </pre>
 385
 386 <p>It's a kernel bug. The function sys_iopl in arch/i386/kernel/ioport.c
 387 does an illegal hack which used to work but is now broken since GCC optimizes
 388 more aggressively . The newer 2.1.x kernels already have a fix which should
 389 also work in 2.0.32.
 390
 391 <hr>
 392 <h2> <a name="memexhausted">Virtual memory exhausted error</a></h2>
 393 <p> This error means your system ran out of memory; this can happen for large
 394 files, particularly when optimizing.  If you're getting this error you should
 395 consider trying to simplify your files or reducing the optimization level.
 396
 397 <p>Note that using -pedantic or -Wreturn-type can cause an explosion in the
 398 amount of memory needed for template-heavy C++ code, such as code that uses
 399 STL.  Also note that -Wall includes -Wreturn-type, so if you use -Wall you
 400 will need to specify -Wno-return-type to turn it off.
 401
 402 <hr>
 403 <h2> <a name="gas">GCC can not find GAS</a></h2>
 404 <p>Some configurations like irix4, irix5, hpux* require the use of the GNU
 405 assembler intead of the system assembler.  To ensure that egcs finds the GNU
 406 assembler, you should configure the GNU assembler with the same --prefix
 407 option as you used for egcs.  Then build & install the GNU assembler.  After
 408 the GNU assembler has been installed, proceed with building egcs.
 409
 410 <hr>
 411 <h2> <a name="rh5.0">egcs does not work on Red Hat 5.0</a></h2>
 412 <p> This entry is obsolete with the release of egcs-1.0.1 which should
 413 handle Red Hat 5.0 correctly.
 414
 415 <p> egcs-1.0 does not currently work with Red Hat 5.0 on some platforms; we'll
 416 update this entry with more information as it becomes available.
 417
 418 <p> You may want to try this
 419 <a href="http://www.cygnus.com/ml/egcs/1997-Dec/0594.html"> proposed patch</a>
 420 for Red Hat 5.0.  Please let us know if you use this patch and whether or
 421 not it works.
 422
 423 <hr>
 424 <h2> <a name="x86solaris">Unable to bootstrap on x86 Solaris 2.{5,6}</a></h2>
 425 <p> This entry is obsolete with the release of egcs-1.0.1 which should
 426 handle x86 Solaris systems correctly.
 427
 428 <p>This patch should fix the problem
 429
 430 <pre>
 431 Index: t-sol2
 432 ===================================================================
 433 RCS file: /cvs/cvsfiles/egcs/gcc/config/i386/t-sol2,v
 434 retrieving revision 1.2
 435 diff -c -3 -p -r1.2 t-sol2
 436 *** t-sol2      1997/09/04 23:54:04     1.2
 437 --- t-sol2      1997/12/04 07:19:07
 438 *************** crtn.o: $(srcdir)/config/i386/sol2-cn.as
 439 *** 31,36 ****
 440   # to produce a shared library, but since we don't know ahead of time when
 441   # we will be doing that, we just always use -fPIC when compiling the
 442   # routines in crtstuff.c.
 443
 444 ! CRTSTUFF_T_CFLAGS = -fPIC
 445   TARGET_LIBGCC2_CFLAGS = -fPIC
 446 --- 31,40 ----
 447   # to produce a shared library, but since we don't know ahead of time when
 448   # we will be doing that, we just always use -fPIC when compiling the
 449   # routines in crtstuff.c.
 450 + #
 451 + # We must also enable optimization to avoid having any code appear after
 452 + # the call & alignment statement, but before we switch back to the
 453 + # .text section.
 454
 455 ! CRTSTUFF_T_CFLAGS = -fPIC -O2
 456   TARGET_LIBGCC2_CFLAGS = -fPIC
 457 </pre>
 458
 459 <hr>
 460 <h2> <a name="windows">EGCS with Windows</a></h2>
 461 <p>egcs does not currently support windows, either natively or with the
 462 cygwin32 dll.  However Mumit Khan has been working on supporting Windows
 463 with egcs.  You should check out his site if you're interested in Windows
 464 support.
 465 <a href="http://www.xraylith.wisc.edu/~khan/software/gnu-win32">GNU Win32 related projects</a>
 466
 467 <hr>
 468 <h2> <a name="environ">cpp: Usage:... Error</a></h2>
 469 <p>If you get an error like this when building egcs (particularly when building
 470 __mulsi3), then you likely have a problem with your environment variables.
 471 <pre>
 472 cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
 473 [switches] input output
 474 </pre>
 475
 476 <p>First look for an explicit '.' in either LIBRARY_PATH or GCC_EXEC_PREFIX
 477 from your environment.  If you do not find an explicit '.', look for
 478 an empty pathname in those variables.  Note that ':' at either the start
 479 or end of these variables is an implicit '.' and will cause problems.
 480
 481 <hr>
 482 <h2> <a name="kde">EGCS will not build KDE</a></h2>
 483 <p> Previous versions of g++ accepted (as a GNU extension)
 484 constructor-arguments for the objects in an array of objects
 485 dynamically allocated with new.  Here's an example of this construct:
 486
 487 <pre>
 488     struct S { S(int); }
 489     void f() { new S[3](6); }
 490 </pre>
 491
 492 <p>However, this construct is not allowed by the ANSI/ISO Standard, and
 493 is no longer accepted by g++.
 494
 495 <p> KDE uses such constructs and therefore will not build with egcs; note
 496 patches are available to fix KDE.
 497
 498
 499
 500
 501 <hr>
 502 <p><a href="index.html">Return to the egcs home page</a>
 503 <p><i>Last modified:  Jan 2, 1998</i>
 504
 505 </body>
 506 </html>