![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-8 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
1.1 root 2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
1.1 root 10:
1.1.1.3 root 11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
1.1 root 14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
1.1.1.4 root 17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
1.1 root 22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
1.1.1.3 root 25: versions, except that the sections entitled "GNU General Public
1.1.1.4 root 26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
1.1.1.2 root 29:
30:
1.1.1.6 ! root 31: File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars
! 32:
! 33: Specifying Registers for Local Variables
! 34: ----------------------------------------
! 35:
! 36: You can define a local register variable with a specified register
! 37: like this:
! 38:
! 39: register int *foo asm ("a5");
! 40:
! 41: Here `a5' is the name of the register which should be used. Note that
! 42: this is the same syntax used for defining global register variables,
! 43: but for a local variable it would appear within a function.
! 44:
! 45: Naturally the register name is cpu-dependent, but this is not a
! 46: problem, since specific registers are most often useful with explicit
! 47: assembler instructions (*note Extended Asm::.). Both of these things
! 48: generally require that you conditionalize your program according to cpu
! 49: type.
! 50:
! 51: In addition, operating systems on one type of cpu may differ in how
! 52: they name the registers; then you would need additional conditionals.
! 53: For example, some 68000 operating systems call this register `%a5'.
! 54:
! 55: Eventually there may be a way of asking the compiler to choose a
! 56: register automatically, but first we need to figure out how it should
! 57: choose and how to enable you to guide the choice. No solution is
! 58: evident.
! 59:
! 60: Defining such a register variable does not reserve the register; it
! 61: remains available for other uses in places where flow control determines
! 62: the variable's value is not live. However, these registers are made
! 63: unavailable for use in the reload pass. I would not be surprised if
! 64: excessive use of this feature leaves the compiler too few available
! 65: registers to compile certain functions.
! 66:
! 67:
! 68: File: gcc.info, Node: Alternate Keywords, Next: Incomplete Enums, Prev: Explicit Reg Vars, Up: C Extensions
! 69:
! 70: Alternate Keywords
! 71: ==================
! 72:
! 73: The option `-traditional' disables certain keywords; `-ansi'
! 74: disables certain others. This causes trouble when you want to use GNU C
! 75: extensions, or ANSI C features, in a general-purpose header file that
! 76: should be usable by all programs, including ANSI C programs and
! 77: traditional ones. The keywords `asm', `typeof' and `inline' cannot be
! 78: used since they won't work in a program compiled with `-ansi', while
! 79: the keywords `const', `volatile', `signed', `typeof' and `inline' won't
! 80: work in a program compiled with `-traditional'.
! 81:
! 82: The way to solve these problems is to put `__' at the beginning and
! 83: end of each problematical keyword. For example, use `__asm__' instead
! 84: of `asm', `__const__' instead of `const', and `__inline__' instead of
! 85: `inline'.
! 86:
! 87: Other C compilers won't accept these alternative keywords; if you
! 88: want to compile with another compiler, you can define the alternate
! 89: keywords as macros to replace them with the customary keywords. It
! 90: looks like this:
! 91:
! 92: #ifndef __GNUC__
! 93: #define __asm__ asm
! 94: #endif
! 95:
! 96: `-pedantic' causes warnings for many GNU C extensions. You can
! 97: prevent such warnings within one expression by writing `__extension__'
! 98: before the expression. `__extension__' has no effect aside from this.
! 99:
! 100:
! 101: File: gcc.info, Node: Incomplete Enums, Next: Function Names, Prev: Alternate Keywords, Up: C Extensions
! 102:
! 103: Incomplete `enum' Types
! 104: =======================
! 105:
! 106: You can define an `enum' tag without specifying its possible values.
! 107: This results in an incomplete type, much like what you get if you write
! 108: `struct foo' without describing the elements. A later declaration
! 109: which does specify the possible values completes the type.
! 110:
! 111: You can't allocate variables or storage using the type while it is
! 112: incomplete. However, you can work with pointers to that type.
! 113:
! 114: This extension may not be very useful, but it makes the handling of
! 115: `enum' more consistent with the way `struct' and `union' are handled.
! 116:
! 117:
! 118: File: gcc.info, Node: Function Names, Prev: Incomplete Enums, Up: C Extensions
! 119:
! 120: Function Names as Strings
! 121: =========================
! 122:
! 123: GNU CC predefines two string variables to be the name of the current
! 124: function. The variable `__FUNCTION__' is the name of the function as
! 125: it appears in the source. The variable `__PRETTY_FUNCTION__' is the
! 126: name of the function pretty printed in a language specific fashion.
! 127:
! 128: These names are always the same in a C function, but in a C++
! 129: function they may be different. For example, this program:
! 130:
! 131: extern "C" {
! 132: extern int printf (char *, ...);
! 133: }
! 134:
! 135: class a {
! 136: public:
! 137: sub (int i)
! 138: {
! 139: printf ("__FUNCTION__ = %s\n", __FUNCTION__);
! 140: printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
! 141: }
! 142: };
! 143:
! 144: int
! 145: main (void)
! 146: {
! 147: a ax;
! 148: ax.sub (0);
! 149: return 0;
! 150: }
! 151:
! 152: gives this output:
! 153:
! 154: __FUNCTION__ = sub
! 155: __PRETTY_FUNCTION__ = int a::sub (int)
! 156:
! 157:
! 158: File: gcc.info, Node: C++ Extensions, Next: Trouble, Prev: C Extensions, Up: Top
! 159:
! 160: Extensions to the C++ Language
! 161: ******************************
! 162:
! 163: The GNU compiler provides these extensions to the C++ language (and
! 164: you can also use most of the C language extensions in your C++
! 165: programs). If you want to write code that checks whether these
! 166: features are available, you can test for the GNU compiler the same way
! 167: as for C programs: check for a predefined macro `__GNUC__'. You can
! 168: also use `__GNUG__' to test specifically for GNU C++ (*note Standard
! 169: Predefined Macros: (cpp.info)Standard Predefined.).
! 170:
! 171: * Menu:
! 172:
! 173: * Naming Results:: Giving a name to C++ function return values.
! 174: * Min and Max:: C++ Minimum and maximum operators.
! 175: * Destructors and Goto:: Goto is safe to use in C++ even when destructors
! 176: are needed.
! 177: * C++ Interface:: You can use a single C++ header file for both
! 178: declarations and definitions.
! 179:
! 180:
! 181: File: gcc.info, Node: Naming Results, Next: Min and Max, Up: C++ Extensions
! 182:
! 183: Named Return Values in C++
! 184: ==========================
! 185:
! 186: GNU C++ extends the function-definition syntax to allow you to
! 187: specify a name for the result of a function outside the body of the
! 188: definition, in C++ programs:
! 189:
! 190: TYPE
! 191: FUNCTIONNAME (ARGS) return RESULTNAME;
! 192: {
! 193: ...
! 194: BODY
! 195: ...
! 196: }
! 197:
! 198: You can use this feature to avoid an extra constructor call when a
! 199: function result has a class type. For example, consider a function
! 200: `m', declared as `X v = m ();', whose result is of class `X':
! 201:
! 202: X
! 203: m ()
! 204: {
! 205: X b;
! 206: b.a = 23;
! 207: return b;
! 208: }
! 209:
! 210: Although `m' appears to have no arguments, in fact it has one
! 211: implicit argument: the address of the return value. At invocation, the
! 212: address of enough space to hold `v' is sent in as the implicit argument.
! 213: Then `b' is constructed and its `a' field is set to the value 23.
! 214: Finally, a copy constructor (a constructor of the form `X(X&)') is
! 215: applied to `b', with the (implicit) return value location as the
! 216: target, so that `v' is now bound to the return value.
! 217:
! 218: But this is wasteful. The local `b' is declared just to hold
! 219: something that will be copied right out. While a compiler that
! 220: combined an "elision" algorithm with interprocedural data flow analysis
! 221: could conceivably eliminate all of this, it is much more practical to
! 222: allow you to assist the compiler in generating efficient code by
! 223: manipulating the return value explicitly, thus avoiding the local
! 224: variable and copy constructor altogether.
! 225:
! 226: Using the extended GNU C++ function-definition syntax, you can avoid
! 227: the temporary allocation and copying by naming `r' as your return value
! 228: as the outset, and assigning to its `a' field directly:
! 229:
! 230: X
! 231: m () return r;
! 232: {
! 233: r.a = 23;
! 234: }
! 235:
! 236: The declaration of `r' is a standard, proper declaration, whose effects
! 237: are executed *before* any of the body of `m'.
! 238:
! 239: Functions of this type impose no additional restrictions; in
! 240: particular, you can execute `return' statements, or return implicitly by
! 241: reaching the end of the function body ("falling off the edge"). Cases
! 242: like
! 243:
! 244: X
! 245: m () return r (23);
! 246: {
! 247: return;
! 248: }
! 249:
! 250: (or even `X m () return r (23); { }') are unambiguous, since the return
! 251: value `r' has been initialized in either case. The following code may
! 252: be hard to read, but also works predictably:
! 253:
! 254: X
! 255: m () return r;
! 256: {
! 257: X b;
! 258: return b;
! 259: }
! 260:
! 261: The return value slot denoted by `r' is initialized at the outset,
! 262: but the statement `return b;' overrides this value. The compiler deals
! 263: with this by destroying `r' (calling the destructor if there is one, or
! 264: doing nothing if there is not), and then reinitializing `r' with `b'.
! 265:
! 266: This extension is provided primarily to help people who use
! 267: overloaded operators, where there is a great need to control not just
! 268: the arguments, but the return values of functions. For classes where
! 269: the copy constructor incurs a heavy performance penalty (especially in
! 270: the common case where there is a quick default constructor), this is a
! 271: major savings. The disadvantage of this extension is that you do not
! 272: control when the default constructor for the return value is called: it
! 273: is always called at the beginning.
! 274:
! 275:
! 276: File: gcc.info, Node: Min and Max, Next: Destructors and Goto, Prev: Naming Results, Up: C++ Extensions
! 277:
! 278: Minimum and Maximum Operators in C++
! 279: ====================================
! 280:
! 281: It is very convenient to have operators which return the "minimum"
! 282: or the "maximum" of two arguments. In GNU C++ (but not in GNU C),
! 283:
! 284: `A <? B'
! 285: is the "minimum", returning the smaller of the numeric values A
! 286: and B;
! 287:
! 288: `A >? B'
! 289: is the "maximum", returning the larger of the numeric values A and
! 290: B.
! 291:
! 292: These operations are not primitive in ordinary C++, since you can
! 293: use a macro to return the minimum of two things in C++, as in the
! 294: following example.
! 295:
! 296: #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
! 297:
! 298: You might then use `int min = MIN (i, j);' to set MIN to the minimum
! 299: value of variables I and J.
! 300:
! 301: However, side effects in `X' or `Y' may cause unintended behavior.
! 302: For example, `MIN (i++, j++)' will fail, incrementing the smaller
! 303: counter twice. A GNU C extension allows you to write safe macros that
! 304: avoid this kind of problem (*note Naming an Expression's Type: Naming
! 305: Types.). However, writing `MIN' and `MAX' as macros also forces you to
! 306: use function-call notation notation for a fundamental arithmetic
! 307: operation. Using GNU C++ extensions, you can write `int min = i <? j;'
! 308: instead.
! 309:
! 310: Since `<?' and `>?' are built into the compiler, they properly
! 311: handle expressions with side-effects; `int min = i++ <? j++;' works
! 312: correctly.
! 313:
! 314:
! 315: File: gcc.info, Node: Destructors and Goto, Next: C++ Interface, Prev: Min and Max, Up: C++ Extensions
! 316:
! 317: `goto' and Destructors in GNU C++
! 318: =================================
! 319:
! 320: In C++ programs, you can safely use the `goto' statement. When you
! 321: use it to exit a block which contains aggregates requiring destructors,
! 322: the destructors will run before the `goto' transfers control. (In ANSI
! 323: C++, `goto' is restricted to targets within the current block.)
! 324:
! 325: The compiler still forbids using `goto' to *enter* a scope that
! 326: requires constructors.
! 327:
! 328:
1.1.1.5 root 329: File: gcc.info, Node: C++ Interface, Prev: Destructors and Goto, Up: C++ Extensions
330:
331: Declarations and Definitions in One Header
332: ==========================================
1.1.1.2 root 333:
1.1.1.5 root 334: C++ object definitions can be quite complex. In principle, your
335: source code will need two kinds of things for each object that you use
336: across more than one source file. First, you need an "interface"
337: specification, describing its structure with type declarations and
338: function prototypes. Second, you need the "implementation" itself. It
339: can be tedious to maintain a separate interface description in a header
340: file, in parallel to the actual implementation. It is also dangerous,
341: since separate interface and implementation definitions may not remain
342: parallel.
343:
344: With GNU C++, you can use a single header file for both purposes.
345:
346: *Warning:* The mechanism to specify this is in transition. For the
347: nonce, you must use one of two `#pragma' commands; in a future
348: release of GNU C++, an alternative mechanism will make these
349: `#pragma' commands unnecessary.
350:
351: The header file contains the full definitions, but is marked with
352: `#pragma interface' in the source code. This allows the compiler to
353: use the header file only as an interface specification when ordinary
354: source files incorporate it with `#include'. In the single source file
355: where the full implementation belongs, you can use either a naming
356: convention or `#pragma implementation' to indicate this alternate use
357: of the header file.
358:
359: `#pragma interface'
360: Use this directive in *header files* that define object classes,
361: to save space in most of the object files that use those classes.
362: Normally, local copies of certain information (backup copies of
363: inline member functions, debugging information, and the internal
364: tables that implement virtual functions) must be kept in each
365: object file that includes class definitions. You can use this
366: pragma to avoid such duplication. When a header file containing
367: `#pragma interface' is included in a compilation, this auxiliary
368: information will not be generated (unless the main input source
369: file itself uses `#pragma implementation'). Instead, the object
370: files will contain references to be resolved at link time.
371:
372: `#pragma implementation'
373: `#pragma implementation "OBJECTS.h"'
374: Use this pragma in a *main input file*, when you want full output
375: from included header files to be generated (and made globally
376: visible). The included header file, in turn, should use `#pragma
377: interface'. Backup copies of inline member functions, debugging
378: information, and the internal tables used to implement virtual
379: functions are all generated in implementation files.
380:
381: `#pragma implementation' is *implied* whenever the basename(1) of
382: your source file matches the basename of a header file it
383: includes. There is no way to turn this off (other than using a
384: different name for one of the two files). In the same vein, if
385: you use `#pragma implementation' with no argument, it applies to an
386: include file with the same basename as your source file. For
387: example, in `allclass.cc', `#pragma implementation' by itself is
388: equivalent to `#pragma implementation "allclass.h"'; but even if
389: you do not say `#pragma implementation' at all, `allclass.h' is
390: treated as an implementation file whenever you include it from
391: `allclass.cc'.
392:
393: If you use an explicit `#pragma implementation', it must appear in
394: your source file *before* you include the affected header files.
395:
396: Use the string argument if you want a single implementation file to
397: include code from multiple header files. (You must also use
398: `#include' to include the header file; `#pragma implementation'
399: only specifies how to use the file--it doesn't actually include
400: it.)
401:
402: There is no way to split up the contents of a single header file
403: into multiple implementation files.
404:
405: `#pragma implementation' and `#pragma interface' also have an effect
406: on function inlining.
407:
408: If you define a class in a header file marked with `#pragma
409: interface', the effect on a function defined in that class is similar to
410: an explicit `extern' declaration--the compiler emits no code at all to
411: define an independent version of the function. Its definition is used
412: only for inlining with its callers.
413:
414: Conversely, when you include the same header file in a main source
415: file that declares it as `#pragma implementation', the compiler emits
416: code for the function itself; this defines a version of the function
417: that can be found via pointers (or by callers compiled without
418: inlining).
1.1.1.4 root 419:
1.1.1.5 root 420: ---------- Footnotes ----------
1.1.1.4 root 421:
1.1.1.5 root 422: (1) A file's "basename" is the name stripped of all leading path
423: information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
1.1.1.4 root 424:
425:
1.1.1.5 root 426: File: gcc.info, Node: Trouble, Next: Bugs, Prev: C++ Extensions, Up: Top
1.1.1.4 root 427:
1.1.1.5 root 428: Known Causes of Trouble with GNU CC
429: ***********************************
1.1.1.4 root 430:
1.1.1.5 root 431: This section describes known problems that affect users of GNU CC.
432: Most of these are not GNU CC bugs per se--if they were, we would fix
433: them. But the result for a user may be like the result of a bug.
434:
435: Some of these problems are due to bugs in other software, some are
436: missing features that are too much work to add, and some are places
437: where people's opinions differ as to what is best.
1.1.1.4 root 438:
1.1.1.5 root 439: * Menu:
1.1.1.4 root 440:
1.1.1.5 root 441: * Actual Bugs:: Bugs we will fix later.
442: * Installation Problems:: Problems that manifest when you install GNU CC.
443: * Cross-Compiler Problems:: Common problems of cross compiling with GNU CC.
444: * Interoperation:: Problems using GNU CC with other compilers,
445: and with certain linkers, assemblers and debuggers.
446: * External Bugs:: Problems compiling certain programs.
447: * Incompatibilities:: GNU CC is incompatible with traditional C.
1.1.1.6 ! root 448: * Fixed Headers:: GNU C uses corrected versions of system header files.
! 449: This is necessary, but doesn't always work smoothly.
1.1.1.5 root 450: * Disappointments:: Regrettable things we can't change, but not quite bugs.
451: * C++ Misunderstandings:: Common misunderstandings with GNU C++.
452: * Protoize Caveats:: Things to watch out for when using `protoize'.
453: * Non-bugs:: Things we think are right, but some others disagree.
454: * Warnings and Errors:: Which problems in your code get warnings,
455: and which get errors.
1.1.1.4 root 456:
457:
1.1.1.5 root 458: File: gcc.info, Node: Actual Bugs, Next: Installation Problems, Up: Trouble
1.1.1.4 root 459:
1.1.1.5 root 460: Actual Bugs We Haven't Fixed Yet
461: ================================
1.1.1.4 root 462:
1.1.1.5 root 463: * The `fixincludes' script interacts badly with automounters; if the
464: directory of system header files is automounted, it tends to be
465: unmounted while `fixincludes' is running. This would seem to be a
466: bug in the automounter. We don't know any good way to work around
467: it.
468:
1.1.1.6 ! root 469: * The `fixproto' script will sometimes add prototypes for the
! 470: `sigsetjmp' and `siglongjmp' functions that reference the
! 471: `jmp_buf' type before that type is defined. To work around this,
! 472: edit the offending file and place the typedef in front of the
! 473: prototypes.
! 474:
1.1.1.5 root 475: * Loop unrolling doesn't work properly for certain C++ programs.
476: This is because of difficulty in updating the debugging
477: information within the loop being unrolled. We plan to revamp the
478: representation of debugging information so that this will work
1.1.1.6 ! root 479: properly, but we have not done this in version 2.5 because we
1.1.1.5 root 480: don't want to delay it any further.
1.1.1.4 root 481:
482:
1.1.1.5 root 483: File: gcc.info, Node: Installation Problems, Next: Cross-Compiler Problems, Prev: Actual Bugs, Up: Trouble
1.1.1.4 root 484:
1.1.1.5 root 485: Installation Problems
1.1.1.2 root 486: =====================
487:
1.1.1.5 root 488: This is a list of problems (and some apparent problems which don't
489: really mean anything is wrong) that show up during installation of GNU
490: CC.
491:
492: * On certain systems, defining certain environment variables such as
493: `CC' can interfere with the functioning of `make'.
494:
495: * If you encounter seemingly strange errors when trying to build the
496: compiler in a directory other than the source directory, it could
497: be because you have previously configured the compiler in the
498: source directory. Make sure you have done all the necessary
499: preparations. *Note Other Dir::.
500:
1.1.1.6 ! root 501: * If you build GNU CC on a BSD system using a directory stored in a
! 502: System V file system, problems may occur in running `fixincludes'
! 503: if the System V file system doesn't support symbolic links. These
! 504: problems result in a failure to fix the declaration of `size_t' in
! 505: `sys/types.h'. If you find that `size_t' is a signed type and
! 506: that type mismatches occur, this could be the cause.
! 507:
! 508: The solution is not to use such a directory for building GNU CC.
! 509:
1.1.1.5 root 510: * In previous versions of GNU CC, the `gcc' driver program looked for
511: `as' and `ld' in various places; for example, in files beginning
512: with `/usr/local/lib/gcc-'. GNU CC version 2 looks for them in
513: the directory `/usr/local/lib/gcc-lib/TARGET/VERSION'.
514:
515: Thus, to use a version of `as' or `ld' that is not the system
516: default, for example `gas' or GNU `ld', you must put them in that
517: directory (or make links to them from that directory).
518:
519: * Some commands executed when making the compiler may fail (return a
520: non-zero status) and be ignored by `make'. These failures, which
521: are often due to files that were not found, are expected, and can
522: safely be ignored.
523:
524: * It is normal to have warnings in compiling certain files about
525: unreachable code and about enumeration type clashes. These files'
526: names begin with `insn-'. Also, `real.c' may get some warnings
527: that you can ignore.
528:
529: * Sometimes `make' recompiles parts of the compiler when installing
530: the compiler. In one case, this was traced down to a bug in
531: `make'. Either ignore the problem or switch to GNU Make.
532:
533: * If you have installed a program known as purify, you may find that
534: it causes errors while linking `enquire', which is part of building
535: GNU CC. The fix is to get rid of the file `real-ld' which purify
536: installs--so that GNU CC won't try to use it.
537:
538: * On Linux SLS 1.01, there is a problem with `libc.a': it does not
539: contain the obstack functions. However, GNU CC assumes that the
540: obstack functions are in `libc.a' when it is the GNU C library.
541: To work around this problem, change the `__GNU_LIBRARY__'
542: conditional around line 31 to `#if 1'.
543:
544: * On some 386 systems, building the compiler never finishes because
545: `enquire' hangs due to a hardware problem in the motherboard--it
546: reports floating point exceptions to the kernel incorrectly. You
547: can install GNU CC except for `float.h' by patching out the
548: command to run `enquire'. You may also be able to fix the problem
549: for real by getting a replacement motherboard. This problem was
550: observed in Revision E of the Micronics motherboard, and is fixed
1.1.1.6 ! root 551: in Revision F. It has also been observed in the MYLEX MXA-33
! 552: motherboard.
! 553:
! 554: If you encounter this problem, you may also want to consider
! 555: removing the FPU from the socket during the compilation.
! 556: Alternatively, if you are running SCO Unix, you can reboot and
! 557: force the FPU to be ignored. To do this, type `hd(40)unix auto
! 558: ignorefpu'.
1.1.1.5 root 559:
560: * On some 386 systems, GNU CC crashes trying to compile `enquire.c'.
561: This happens on machines that don't have a 387 FPU chip. On 386
562: machines, the system kernel is supposed to emulate the 387 when you
563: don't have one. The crash is due to a bug in the emulator.
564:
565: One of these systems is the Unix from Interactive Systems: 386/ix.
566: On this system, an alternate emulator is provided, and it does
567: work. To use it, execute this command as super-user:
568:
569: ln /etc/emulator.rel1 /etc/emulator
570:
571: and then reboot the system. (The default emulator file remains
572: present under the name `emulator.dflt'.)
573:
574: Try using `/etc/emulator.att', if you have such a problem on the
575: SCO system.
576:
577: Another system which has this problem is Esix. We don't know
578: whether it has an alternate emulator that works.
579:
580: On NetBSD 0.8, a similar problem manifests itself as these error
581: messages:
582:
583: enquire.c: In function `fprop':
584: enquire.c:2328: floating overflow
585:
1.1.1.6 ! root 586: * On SCO systems, when compiling GNU CC with the system's compiler,
! 587: do not use `-O'. Some versions of the system's compiler miscompile
! 588: GNU CC with `-O'.
! 589:
1.1.1.5 root 590: * Sometimes on a Sun 4 you may observe a crash in the program
591: `genflags' or `genoutput' while building GNU CC. This is said to
592: be due to a bug in `sh'. You can probably get around it by running
593: `genflags' or `genoutput' manually and then retrying the `make'.
594:
595: * On Solaris 2, executables of GNU CC version 2.0.2 are commonly
596: available, but they have a bug that shows up when compiling current
597: versions of GNU CC: undefined symbol errors occur during assembly
598: if you use `-g'.
599:
600: The solution is to compile the current version of GNU CC without
601: `-g'. That makes a working compiler which you can use to recompile
602: with `-g'.
603:
1.1.1.6 ! root 604: * Solaris 2 comes with a number of optional OS packages. Some of
1.1.1.5 root 605: these packages are needed to use GNU CC fully. If you did not
606: install all optional packages when installing Solaris, you will
1.1.1.6 ! root 607: need to verify that the packages that GNU CC needs are installed.
! 608:
! 609: To check whether an optional package is installed, use the
! 610: `pkginfo' command. To add an optional package, use the `pkgadd'
! 611: command. For further details, see the Solaris documentation.
! 612:
! 613: For Solaris 2.0 and 2.1, GNU CC needs six packages: `SUNWarc',
! 614: `SUNWbtool', `SUNWesu', `SUNWhea', `SUNWlibm', and `SUNWtoo'.
1.1.1.5 root 615:
1.1.1.6 ! root 616: For Solaris 2.2, GNU CC needs an additional seventh package:
! 617: `SUNWsprot'.
1.1.1.5 root 618:
619: * On Solaris 2, trying to use the linker and other tools in
620: `/usr/ucb' to install GNU CC has been observed to cause trouble.
621: For example, the linker may hang indefinitely. The fix is to
622: remove `/usr/ucb' from your `PATH'.
623:
624: * If you use the 1.31 version of the MIPS assembler (such as was
625: shipped with Ultrix 3.1), you will need to use the
626: -fno-delayed-branch switch when optimizing floating point code.
627: Otherwise, the assembler will complain when the GCC compiler fills
628: a branch delay slot with a floating point instruction, such as
1.1.1.6 ! root 629: `add.d'.
1.1.1.5 root 630:
631: * If on a MIPS system you get an error message saying "does not have
632: gp sections for all it's [sic] sectons [sic]", don't worry about
633: it. This happens whenever you use GAS with the MIPS linker, but
634: there is not really anything wrong, and it is okay to use the
635: output file. You can stop such warnings by installing the GNU
636: linker.
637:
638: It would be nice to extend GAS to produce the gp tables, but they
639: are optional, and there should not be a warning about their
640: absence.
641:
1.1.1.6 ! root 642: * In Ultrix 4.0 on the MIPS machine, `stdio.h' does not work with GNU
! 643: CC at all unless it has been fixed with `fixincludes'. This causes
! 644: problems in building GNU CC. Once GNU CC is installed, the
! 645: problems go away.
! 646:
! 647: To work around this problem, when making the stage 1 compiler,
! 648: specify this option to Make:
! 649:
! 650: GCC_FOR_TARGET="./xgcc -B./ -I./include"
! 651:
! 652: When making stage 2 and stage 3, specify this option:
! 653:
! 654: CFLAGS="-g -I./include"
! 655:
1.1.1.5 root 656: * Users have reported some problems with version 2.0 of the MIPS
657: compiler tools that were shipped with Ultrix 4.1. Version 2.10
658: which came with Ultrix 4.2 seems to work fine.
659:
660: * Some versions of the MIPS linker will issue an assertion failure
661: when linking code that uses `alloca' against shared libraries on
662: RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug in the
663: linker, that is supposed to be fixed in future revisions. To
1.1.1.6 ! root 664: protect against this, GNU CC passes `-non_shared' to the linker
1.1.1.5 root 665: unless you pass an explicit `-shared' or `-call_shared' switch.
666:
667: * On System V release 3, you may get this error message while
668: linking:
669:
670: ld fatal: failed to write symbol name SOMETHING
671: in strings table for file WHATEVER
672:
673: This probably indicates that the disk is full or your ULIMIT won't
674: allow the file to be as large as it needs to be.
675:
676: This problem can also result because the kernel parameter `MAXUMEM'
677: is too small. If so, you must regenerate the kernel and make the
678: value much larger. The default value is reported to be 1024; a
679: value of 32768 is said to work. Smaller values may also work.
680:
681: * On System V, if you get an error like this,
682:
683: /usr/local/lib/bison.simple: In function `yyparse':
684: /usr/local/lib/bison.simple:625: virtual memory exhausted
685:
686: that too indicates a problem with disk space, ULIMIT, or `MAXUMEM'.
687:
688: * Current GNU CC versions probably do not work on version 2 of the
689: NeXT operating system.
690:
1.1.1.6 ! root 691: * On NeXTStep 3.0, the Objective C compiler does not work, due,
! 692: apparently, to a kernel bug that it happens to trigger. This
! 693: problem does not happen on 3.1.
! 694:
1.1.1.5 root 695: * On the Tower models 4N0 and 6N0, by default a process is not
696: allowed to have more than one megabyte of memory. GNU CC cannot
697: compile itself (or many other programs) with `-O' in that much
698: memory.
699:
700: To solve this problem, reconfigure the kernel adding the following
701: line to the configuration file:
702:
703: MAXUMEM = 4096
704:
705: * On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a
706: bug in the assembler that must be fixed before GNU CC can be
707: built. This bug manifests itself during the first stage of
708: compilation, while building `libgcc2.a':
709:
710: _floatdisf
711: cc1: warning: `-g' option not supported on this version of GCC
712: cc1: warning: `-g1' option not supported on this version of GCC
713: ./xgcc: Internal compiler error: program as got fatal signal 11
714:
715: A patched version of the assembler is available by anonymous ftp
716: from `altdorf.ai.mit.edu' as the file
717: `archive/cph/hpux-8.0-assembler'. If you have HP software support,
718: the patch can also be obtained directly from HP, as described in
719: the following note:
720:
721: This is the patched assembler, to patch SR#1653-010439, where
722: the assembler aborts on floating point constants.
723:
724: The bug is not really in the assembler, but in the shared
725: library version of the function "cvtnum(3c)". The bug on
726: "cvtnum(3c)" is SR#4701-078451. Anyway, the attached
727: assembler uses the archive library version of "cvtnum(3c)"
728: and thus does not exhibit the bug.
729:
730: This patch is also known as PHCO_0800.
731:
1.1.1.6 ! root 732: * On HP-UX version 8.05, but not on 8.07 or more recent versions,
! 733: the `fixproto' shell script triggers a bug in the system shell.
! 734: If you encounter this problem, upgrade your operating system or
! 735: use BASH (the GNU shell) to run `fixproto'.
1.1.1.5 root 736:
737: * Some versions of the Pyramid C compiler are reported to be unable
738: to compile GNU CC. You must use an older version of GNU CC for
739: bootstrapping. One indication of this problem is if you get a
740: crash when GNU CC compiles the function `muldi3' in file
741: `libgcc2.c'.
742:
743: You may be able to succeed by getting GNU CC version 1, installing
744: it, and using it to compile GNU CC version 2. The bug in the
745: Pyramid C compiler does not seem to affect GNU CC version 1.
746:
747: * There may be similar problems on System V Release 3.1 on 386
748: systems.
749:
1.1.1.6 ! root 750: * On the Intel Paragon (an i860 machine), if you are using operating
! 751: system version 1.0, you will get warnings or errors about
! 752: redefinition of `va_arg' when you build GNU CC.
! 753:
! 754: If this happens, then you need to link most programs with the
! 755: library `iclib.a'. You must also modify `stdio.h' as follows:
! 756: before the lines
! 757:
! 758: #if defined(__i860__) && !defined(_VA_LIST)
! 759: #include <va_list.h>
! 760:
! 761: insert the line
! 762:
! 763: #if __PGC__
! 764:
! 765: and after the lines
! 766:
! 767: extern int vprintf(const char *, va_list );
! 768: extern int vsprintf(char *, const char *, va_list );
! 769: #endif
! 770:
! 771: insert the line
! 772:
! 773: #endif /* __PGC__ */
! 774:
! 775: These problems don't exist in operating system version 1.1.
! 776:
1.1.1.5 root 777: * On the Altos 3068, programs compiled with GNU CC won't work unless
778: you fix a kernel bug. This happens using system versions V.2.2
779: 1.0gT1 and V.2.2 1.0e and perhaps later versions as well. See the
780: file `README.ALTOS'.
781:
782: * You will get several sorts of compilation and linking errors on the
783: we32k if you don't follow the special instructions. *Note WE32K
784: Install::.
1.1.1.4 root 785:
786:
1.1.1.5 root 787: File: gcc.info, Node: Cross-Compiler Problems, Next: Interoperation, Prev: Installation Problems, Up: Trouble
1.1.1.4 root 788:
1.1.1.5 root 789: Cross-Compiler Problems
790: =======================
791:
792: You may run into problems with cross compilation on certain machines,
793: for several reasons.
1.1.1.4 root 794:
1.1.1.5 root 795: * Cross compilation can run into trouble for certain machines because
796: some target machines' assemblers require floating point numbers to
797: be written as *integer* constants in certain contexts.
798:
799: The compiler writes these integer constants by examining the
800: floating point value as an integer and printing that integer,
801: because this is simple to write and independent of the details of
802: the floating point representation. But this does not work if the
803: compiler is running on a different machine with an incompatible
804: floating point format, or even a different byte-ordering.
805:
806: In addition, correct constant folding of floating point values
807: requires representing them in the target machine's format. (The C
808: standard does not quite require this, but in practice it is the
809: only way to win.)
810:
811: It is now possible to overcome these problems by defining macros
812: such as `REAL_VALUE_TYPE'. But doing so is a substantial amount of
813: work for each target machine. *Note Cross-compilation::.
814:
815: * At present, the program `mips-tfile' which adds debug support to
816: object files on MIPS systems does not work in a cross compile
817: environment.
1.1.1.4 root 818:
819:
1.1.1.5 root 820: File: gcc.info, Node: Interoperation, Next: External Bugs, Prev: Cross-Compiler Problems, Up: Trouble
1.1.1.4 root 821:
1.1.1.5 root 822: Interoperation
823: ==============
1.1.1.4 root 824:
1.1.1.5 root 825: This section lists various difficulties encountered in using GNU C or
826: GNU C++ together with other compilers or with the assemblers, linkers,
827: libraries and debuggers on certain systems.
828:
1.1.1.6 ! root 829: * Objective C does not work on the RS/6000 or the Alpha.
1.1.1.5 root 830:
831: * C++ does not work on the Alpha.
832:
833: * GNU C++ does not do name mangling in the same way as other C++
834: compilers. This means that object files compiled with one compiler
835: cannot be used with another.
836:
837: This effect is intentional, to protect you from more subtle
838: problems. Compilers differ as to many internal details of C++
839: implementation, including: how class instances are laid out, how
840: multiple inheritance is implemented, and how virtual function
841: calls are handled. If the name encoding were made the same, your
842: programs would link against libraries provided from other
843: compilers--but the programs would then crash when run.
844: Incompatible libraries are then detected at link time, rather than
845: at run time.
846:
847: * Older GDB versions sometimes fail to read the output of GNU CC
848: version 2. If you have trouble, get GDB version 4.4 or later.
849:
850: * DBX rejects some files produced by GNU CC, though it accepts
851: similar constructs in output from PCC. Until someone can supply a
852: coherent description of what is valid DBX input and what is not,
853: there is nothing I can do about these problems. You are on your
854: own.
855:
856: * The GNU assembler (GAS) does not support PIC. To generate PIC
857: code, you must use some other assembler, such as `/bin/as'.
858:
1.1.1.6 ! root 859: * On some BSD systems, including some versions of Ultrix, use of
1.1.1.5 root 860: profiling causes static variable destructors (currently used only
861: in C++) not to be run.
862:
863: * Use of `-I/usr/include' may cause trouble.
864:
865: Many systems come with header files that won't work with GNU CC
866: unless corrected by `fixincludes'. The corrected header files go
867: in a new directory; GNU CC searches this directory before
868: `/usr/include'. If you use `-I/usr/include', this tells GNU CC to
869: search `/usr/include' earlier on, before the corrected headers.
870: The result is that you get the uncorrected header files.
871:
872: Instead, you should use these options (when compiling C programs):
873:
874: -I/usr/local/lib/gcc-lib/TARGET/VERSION/include -I/usr/include
875:
876: For C++ programs, GNU CC also uses a special directory that
877: defines C++ interfaces to standard C subroutines. This directory
878: is meant to be searched *before* other standard include
879: directories, so that it takes precedence. If you are compiling
880: C++ programs and specifying include directories explicitly, use
881: this option first, then the two options above:
882:
883: -I/usr/local/lib/g++-include
884:
1.1.1.6 ! root 885: * On some SGI systems, when you use `-lgl_s' as an option, it gets
! 886: translated magically to `-lgl_s -lX11_s -lc_s'. Naturally, this
! 887: does not happen when you use GNU CC. You must specify all three
! 888: options explicitly.
! 889:
1.1.1.5 root 890: * On a Sparc, GNU CC aligns all values of type `double' on an 8-byte
891: boundary, and it expects every `double' to be so aligned. The Sun
892: compiler usually gives `double' values 8-byte alignment, with one
893: exception: function arguments of type `double' may not be aligned.
894:
895: As a result, if a function compiled with Sun CC takes the address
896: of an argument of type `double' and passes this pointer of type
897: `double *' to a function compiled with GNU CC, dereferencing the
898: pointer may cause a fatal signal.
899:
900: One way to solve this problem is to compile your entire program
901: with GNU CC. Another solution is to modify the function that is
902: compiled with Sun CC to copy the argument into a local variable;
903: local variables are always properly aligned. A third solution is
904: to modify the function that uses the pointer to dereference it via
905: the following function `access_double' instead of directly with
906: `*':
907:
908: inline double
909: access_double (double *unaligned_ptr)
910: {
911: union d2i { double d; int i[2]; };
912:
913: union d2i *p = (union d2i *) unaligned_ptr;
914: union d2i u;
915:
916: u.i[0] = p->i[0];
917: u.i[1] = p->i[1];
918:
919: return u.d;
920: }
921:
922: Storing into the pointer can be done likewise with the same union.
923:
924: * On Solaris, the `malloc' function in the `libmalloc.a' library may
925: allocate memory that is only 4 byte aligned. Since GNU CC on the
926: Sparc assumes that doubles are 8 byte aligned, this may result in a
927: fatal signal if doubles are stored in memory allocated by the
928: `libmalloc.a' library.
929:
930: The solution is to not use the `libmalloc.a' library. Use instead
931: `malloc' and related functions from `libc.a'; they do not have
932: this problem.
933:
934: * On a Sun, linking using GNU CC fails to find a shared library and
935: reports that the library doesn't exist at all.
936:
937: This happens if you are using the GNU linker, because it does only
938: static linking and looks only for unshared libraries. If you have
939: a shared library with no unshared counterpart, the GNU linker
940: won't find anything.
941:
942: We hope to make a linker which supports Sun shared libraries, but
943: please don't ask when it will be finished--we don't know.
944:
945: * Sun forgot to include a static version of `libdl.a' with some
946: versions of SunOS (mainly 4.1). This results in undefined symbols
947: when linking static binaries (that is, if you use `-static'). If
948: you see undefined symbols `_dlclose', `_dlsym' or `_dlopen' when
949: linking, compile and link against the file `mit/util/misc/dlsym.c'
950: from the MIT version of X windows.
951:
1.1.1.6 ! root 952: * The 128-bit long double format that the Sparc port supports
! 953: currently works by using the architecturally defined quad-word
! 954: floating point instructions. Since there is no hardware that
! 955: supports these instructions they must be emulated by the operating
! 956: system. Long doubles do not work in Sun OS versions 4.0.3 and
! 957: earlier, because the kernel eumulator uses an obsolete and
! 958: incompatible format. Long doubles do not work in Sun OS versions
! 959: 4.1.1 to 4.1.3 because of emululator bugs that cause random
! 960: unpredicatable failures. Long doubles appear to work in Sun OS 5.x
! 961: (Solaris 2.x).
! 962:
! 963: A future implementation of the sparc long double support will use
! 964: functions calls to library routines instead of the quad-word
! 965: floating point instructions. This will allow long doubles to work
! 966: in more situtations, since one can then substitute a working
! 967: library if the kernel emulator is buggy.
! 968:
! 969: * On HP-UX version 9.01 on the HP PA, the HP compiler `cc' does not
! 970: compile GNU CC correctly. We do not yet know why. However, GNU CC
! 971: compiled on earlier HP-UX versions works properly on HP-UX 9.01
! 972: and can compile itself properly on 9.01.
! 973:
1.1.1.5 root 974: * On the HP PA machine, ADB sometimes fails to work on functions
975: compiled with GNU CC. Specifically, it fails to work on functions
976: that use `alloca' or variable-size arrays. This is because GNU CC
977: doesn't generate HP-UX unwind descriptors for such functions. It
978: may even be impossible to generate them.
979:
980: * Debugging (`-g') is not supported on the HP PA machine, unless you
981: use the preliminary GNU tools (*note Installation::.).
982:
983: * Taking the address of a label may generate errors from the HP-UX
984: PA assembler. GAS for the PA does not have this problem.
985:
1.1.1.6 ! root 986: * Using floating point parameters for indirect calls to static
! 987: functions will not work when using the HP assembler. There simply
! 988: is no way for GCC to specify what registers hold arguments for
! 989: static functions when using the HP assembler. GAS for the PA does
! 990: not have this problem.
! 991:
! 992: * For some very large functions you may receive errors from the HP
! 993: linker complaining about an out of bounds unconditional branch
! 994: offset. Fixing this problem correctly requires fixing problems in
! 995: GNU CC and GAS. We hope to fix this in time for GNU CC 2.6.
! 996: Until then you can work around by making your function smaller,
! 997: and if you are using GAS, splitting the function into multiple
! 998: source files may be necessary.
1.1.1.5 root 999:
1000: * GNU CC compiled code sometimes emits warnings from the HP-UX
1001: assembler of the form:
1002:
1003: (warning) Use of GR3 when
1004: frame >= 8192 may cause conflict.
1005:
1006: These warnings are harmless and can be safely ignored.
1007:
1008: * The current version of the assembler (`/bin/as') for the RS/6000
1009: has certain problems that prevent the `-g' option in GCC from
1010: working. Note that `Makefile.in' uses `-g' by default when
1011: compiling `libgcc2.c'.
1012:
1013: IBM has produced a fixed version of the assembler. The upgraded
1014: assembler unfortunately was not included in any of the AIX 3.2
1015: update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1
1016: should request PTF U403044 from IBM and users of AIX 3.2 should
1017: request PTF U416277. See the file `README.RS6000' for more
1018: details on these updates.
1019:
1020: You can test for the presense of a fixed assembler by using the
1021: command
1022:
1023: as -u < /dev/null
1024:
1025: If the command exits normally, the assembler fix already is
1026: installed. If the assembler complains that "-u" is an unknown
1027: flag, you need to order the fix.
1028:
1029: * On the IBM RS/6000, compiling code of the form
1030:
1031: extern int foo;
1032:
1033: ... foo ...
1034:
1035: static int foo;
1036:
1037: will cause the linker to report an undefined symbol `foo'.
1038: Although this behavior differs from most other systems, it is not a
1039: bug because redefining an `extern' variable as `static' is
1040: undefined in ANSI C.
1041:
1042: * AIX on the RS/6000 provides support (NLS) for environments outside
1043: of the United States. Compilers and assemblers use NLS to support
1044: locale-specific representations of various objects including
1045: floating-point numbers ("." vs "," for separating decimal
1046: fractions). There have been problems reported where the library
1047: linked with GCC does not produce the same floating-point formats
1048: that the assembler accepts. If you have this problem, set the
1049: LANG environment variable to "C" or "En_US".
1050:
1.1.1.6 ! root 1051: * On the RS/6000, XLC version 1.3.0.0 will miscompile `jump.c'. XLC
! 1052: version 1.3.0.1 or later fixes this problem. We do not yet have a
! 1053: PTF number for this fix.
! 1054:
1.1.1.5 root 1055: * There is an assembler bug in versions of DG/UX prior to 5.4.2.01
1056: that occurs when the `fldcr' instruction is used. GNU CC uses
1057: `fldcr' on the 88100 to serialize volatile memory references. Use
1.1.1.6 ! root 1058: the option `-mno-serialize-volatile' if your version of the
1.1.1.5 root 1059: assembler has this bug.
1060:
1061: * On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
1062: messages from the linker. These warning messages complain of
1063: mismatched psect attributes. You can ignore them. *Note VMS
1064: Install::.
1065:
1066: * On NewsOS version 3, if you include both of the files `stddef.h'
1067: and `sys/types.h', you get an error because there are two typedefs
1068: of `size_t'. You should change `sys/types.h' by adding these
1069: lines around the definition of `size_t':
1070:
1071: #ifndef _SIZE_T
1072: #define _SIZE_T
1073: ACTUAL TYPEDEF HERE
1074: #endif
1075:
1076: * On the Alliant, the system's own convention for returning
1077: structures and unions is unusual, and is not compatible with GNU
1078: CC no matter what options are used.
1079:
1080: * On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
1081: convention for structure and union returning. Use the option
1082: `-mhc-struct-return' to tell GNU CC to use a convention compatible
1083: with it.
1084:
1085: * On Ultrix, the Fortran compiler expects registers 2 through 5 to
1086: be saved by function calls. However, the C compiler uses
1087: conventions compatible with BSD Unix: registers 2 through 5 may be
1088: clobbered by function calls.
1089:
1090: GNU CC uses the same convention as the Ultrix C compiler. You can
1091: use these options to produce code compatible with the Fortran
1092: compiler:
1093:
1094: -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
1095:
1096: * On the WE32k, you may find that programs compiled with GNU CC do
1097: not work with the standard shared C ilbrary. You may need to link
1098: with the ordinary C compiler. If you do so, you must specify the
1099: following options:
1100:
1.1.1.6 ! root 1101: -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.5 -lgcc -lc_s
1.1.1.5 root 1102:
1103: The first specifies where to find the library `libgcc.a' specified
1104: with the `-lgcc' option.
1105:
1106: GNU CC does linking by invoking `ld', just as `cc' does, and there
1107: is no reason why it *should* matter which compilation program you
1108: use to invoke `ld'. If someone tracks this problem down, it can
1109: probably be fixed easily.
1110:
1111: * On the Alpha, you may get assembler errors about invalid syntax as
1112: a result of floating point constants. This is due to a bug in the
1113: C library functions `ecvt', `fcvt' and `gcvt'. Given valid
1114: floating point numbers, they sometimes print `NaN'.
1115:
1116: * On Irix 4.0.5F (and perhaps in some other versions), an assembler
1117: bug sometimes reorders instructions incorrectly when optimization
1118: is turned on. If you think this may be happening to you, try
1119: using the GNU assembler; GAS version 2.1 supports ECOFF on Irix.
1120:
1121: Or use the `-noasmopt' option when you compile GNU CC with itself,
1122: and then again when you compile your program. (This is a temporary
1123: kludge to turn off assembler optimization on Irix.) If this
1124: proves to be what you need, edit the assembler spec in the file
1125: `specs' so that it unconditionally passes `-O0' to the assembler,
1126: and never passes `-O2' or `-O3'.
1.1.1.4 root 1127:
1.1.1.5 root 1128:
1129: File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble
1.1.1.4 root 1130:
1.1.1.5 root 1131: Problems Compiling Certain Programs
1132: ===================================
1.1.1.4 root 1133:
1.1.1.5 root 1134: * Parse errors may occur compiling X11 on a Decstation running
1135: Ultrix 4.2 because of problems in DEC's versions of the X11 header
1136: files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding
1137: `-I/usr/include/mit' to use the MIT versions of the header files,
1138: using the `-traditional' switch to turn off ANSI C, or fixing the
1139: header files by adding this:
1.1.1.4 root 1140:
1.1.1.5 root 1141: #ifdef __STDC__
1142: #define NeedFunctionPrototypes 0
1143: #endif
1.1.1.4 root 1144:
1.1.1.6 ! root 1145: * If you have trouble compiling Perl on a SunOS 4 system, it may be
! 1146: because Perl specifies `-I/usr/ucbinclude'. This accesses the
! 1147: unfixed header files. Perl specifies the options
! 1148:
! 1149: -traditional -Dvolatile=__volatile__
! 1150: -I/usr/include/sun -I/usr/ucbinclude
! 1151: -fpcc-struct-return
! 1152:
! 1153: all of which are unnecessary with GCC 2.4.5 and newer versions.
! 1154: You can make a properly working Perl by setting `ccflags' and
! 1155: `cppflags' to empty values in `config.sh', then typing `./doSH;
! 1156: make depend; make'.
! 1157:
1.1.1.5 root 1158: * On various 386 Unix systems derived from System V, including SCO,
1159: ISC, and ESIX, you may get error messages about running out of
1160: virtual memory while compiling certain programs.
1.1.1.4 root 1161:
1.1.1.5 root 1162: You can prevent this problem by linking GNU CC with the GNU malloc
1163: (which thus replaces the malloc that comes with the system). GNU
1164: malloc is available as a separate package, and also in the file
1165: `src/gmalloc.c' in the GNU Emacs 19 distribution.
1.1.1.4 root 1166:
1.1.1.5 root 1167: If you have installed GNU malloc as a separate library package,
1168: use this option when you relink GNU CC:
1.1.1.4 root 1169:
1.1.1.5 root 1170: MALLOC=/usr/local/lib/libgmalloc.a
1.1.1.4 root 1171:
1.1.1.5 root 1172: Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy
1173: the object file to `gmalloc.o' and use this option when you relink
1174: GNU CC:
1175:
1176: MALLOC=gmalloc.o
1177:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.