From 60ae6360d70362b707910df8cf83b29f1e2a7041 Mon Sep 17 00:00:00 2001 From: Joseph Myers Date: Sat, 25 Sep 2004 01:03:17 +0100 Subject: [PATCH] trouble.texi: Remove obsolete information. * doc/trouble.texi: Remove obsolete information. Update information on how to regenerate fixincluded headers. From-SVN: r88082 --- gcc/ChangeLog | 5 ++ gcc/doc/trouble.texi | 189 +++---------------------------------------- 2 files changed, 14 insertions(+), 180 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 28e360652b2..f967b7b3d95 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2004-09-25 Joseph S. Myers + + * doc/trouble.texi: Remove obsolete information. Update + information on how to regenerate fixincluded headers. + 2004-09-25 Joseph S. Myers PR c/12951 diff --git a/gcc/doc/trouble.texi b/gcc/doc/trouble.texi index 90c4daacc5d..e20604117e0 100644 --- a/gcc/doc/trouble.texi +++ b/gcc/doc/trouble.texi @@ -22,7 +22,6 @@ where people's opinions differ as to what is best. * Cross-Compiler Problems:: Common problems of cross compiling with GCC. * Interoperation:: Problems using GCC with other compilers, and with certain linkers, assemblers and debuggers. -* External Bugs:: Problems compiling certain programs. * Incompatibilities:: GCC is incompatible with traditional C. * Fixed Headers:: GCC uses corrected versions of system header files. This is necessary, but doesn't always work smoothly. @@ -52,12 +51,6 @@ The @code{fixproto} script will sometimes add prototypes for the @code{jmp_buf} type before that type is defined. To work around this, edit the offending file and place the typedef in front of the prototypes. - -@item -@opindex pedantic-errors -When @option{-pedantic-errors} is specified, GCC will incorrectly give -an error message when a function name is specified in an expression -involving the comma operator. @end itemize @node Cross-Compiler Problems @@ -67,29 +60,6 @@ You may run into problems with cross compilation on certain machines, for several reasons. @itemize @bullet -@item -Cross compilation can run into trouble for certain machines because -some target machines' assemblers require floating point numbers to be -written as @emph{integer} constants in certain contexts. - -The compiler writes these integer constants by examining the floating -point value as an integer and printing that integer, because this is -simple to write and independent of the details of the floating point -representation. But this does not work if the compiler is running on -a different machine with an incompatible floating point format, or -even a different byte-ordering. - -In addition, correct constant folding of floating point values -requires representing them in the target machine's format. -(The C standard does not quite require this, but in practice -it is the only way to win.) - -It is now possible to overcome these problems by defining macros such -as @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of -work for each target machine. -@xref{Cross-compilation,,Cross Compilation and Floating Point, -gccint, GNU Compiler Collection (GCC) Internals}. - @item At present, the program @file{mips-tfile} which adds debug support to object files on MIPS systems does not work in a cross @@ -120,42 +90,11 @@ provided from other compilers---but the programs would then crash when run. Incompatible libraries are then detected at link time, rather than at run time. -@item -Older GDB versions sometimes fail to read the output of GCC version -2. If you have trouble, get GDB version 4.4 or later. - -@item -@cindex DBX -DBX rejects some files produced by GCC, though it accepts similar -constructs in output from PCC@. Until someone can supply a coherent -description of what is valid DBX input and what is not, there is -nothing that can be done about these problems. - -@item -The GNU assembler (GAS) does not support PIC@. To generate PIC code, you -must use some other assembler, such as @file{/bin/as}. - @item On some BSD systems, including some versions of Ultrix, use of profiling causes static variable destructors (currently used only in C++) not to be run. -@ignore -@cindex @code{vfork}, for the Sun-4 -@item -There is a bug in @code{vfork} on the Sun-4 which causes the registers -of the child process to clobber those of the parent. Because of this, -programs that call @code{vfork} are likely to lose when compiled -optimized with GCC when the child code alters registers which contain -C variables in the parent. This affects variables which are live in the -parent across the call to @code{vfork}. - -If you encounter this, you can work around the problem by declaring -variables @code{volatile} in the function that calls @code{vfork}, until -the problem goes away, or by not declaring them @code{register} and not -using @option{-O} for those source files. -@end ignore - @item On some SGI systems, when you use @option{-lgl_s} as an option, it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}. @@ -210,32 +149,6 @@ The solution is to not use the @file{libmalloc.a} library. Use instead @code{malloc} and related functions from @file{libc.a}; they do not have this problem. -@item -Sun forgot to include a static version of @file{libdl.a} with some -versions of SunOS (mainly 4.1). This results in undefined symbols when -linking static binaries (that is, if you use @option{-static}). If you -see undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen} -when linking, compile and link against the file -@file{mit/util/misc/dlsym.c} from the MIT version of X windows. - -@item -The 128-bit long double format that the SPARC port supports currently -works by using the architecturally defined quad-word floating point -instructions. Since there is no hardware that supports these -instructions they must be emulated by the operating system. Long -doubles do not work in Sun OS versions 4.0.3 and earlier, because the -kernel emulator uses an obsolete and incompatible format. Long doubles -do not work in Sun OS version 4.1.1 due to a problem in a Sun library. -Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC -does not enable them by default. Long doubles appear to work in Sun OS -5.x (Solaris 2.x). - -@item -On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not -compile GCC correctly. We do not yet know why. However, GCC -compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can -compile itself properly on 9.01. - @item On the HP PA machine, ADB sometimes fails to work on functions compiled with GCC@. Specifically, it fails to work on functions that use @@ -275,23 +188,6 @@ the form: These warnings are harmless and can be safely ignored. -@item -On the IBM RS/6000, compiling code of the form - -@smallexample -extern int foo; - -@dots{} foo @dots{} - -static int foo; -@end smallexample - -@noindent -will cause the linker to report an undefined symbol @code{foo}. -Although this behavior differs from most other systems, it is not a -bug because redefining an @code{extern} variable as @code{static} -is undefined in ISO C@. - @item In extremely rare cases involving some very large functions you may receive errors from the AIX Assembler complaining about a displacement @@ -352,58 +248,6 @@ these options to produce code compatible with the Fortran compiler: @smallexample -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 @end smallexample - -@item -On the Alpha, you may get assembler errors about invalid syntax as a -result of floating point constants. This is due to a bug in the C -library functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid -floating point numbers, they sometimes print @samp{NaN}. -@end itemize - -@node External Bugs -@section Problems Compiling Certain Programs - -@c prevent bad page break with this line -Certain programs have problems compiling. - -@itemize @bullet -@item -Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2 -because of problems in DEC's versions of the X11 header files -@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding -@option{-I/usr/include/mit} to use the MIT versions of the header files, -or fixing the header files by adding this: - -@smallexample -#ifdef __STDC__ -#define NeedFunctionPrototypes 0 -#endif -@end smallexample - -@item -On various 386 Unix systems derived from System V, including SCO, ISC, -and ESIX, you may get error messages about running out of virtual memory -while compiling certain programs. - -You can prevent this problem by linking GCC with the GNU malloc -(which thus replaces the malloc that comes with the system). GNU malloc -is available as a separate package, and also in the file -@file{src/gmalloc.c} in the GNU Emacs 19 distribution. - -If you have installed GNU malloc as a separate library package, use this -option when you relink GCC: - -@smallexample -MALLOC=/usr/local/lib/libgmalloc.a -@end smallexample - -Alternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy -the object file to @file{gmalloc.o} and use this option when you relink -GCC: - -@smallexample -MALLOC=gmalloc.o -@end smallexample @end itemize @node Incompatibilities @@ -662,8 +506,7 @@ incompatible with ISO C, and some depend on special features of other compilers. Installing GCC automatically creates and installs the fixed header -files, by running a program called @code{fixincludes} (or for certain -targets an alternative such as @code{fixinc.svr4}). Normally, you +files, by running a program called @code{fixincludes}. Normally, you don't need to pay attention to this. But there are cases where it doesn't do the right thing automatically. @@ -671,35 +514,23 @@ doesn't do the right thing automatically. @item If you update the system's header files, such as by installing a new system version, the fixed header files of GCC are not automatically -updated. The easiest way to update them is to reinstall GCC@. (If -you want to be clever, look in the makefile and you can find a -shortcut.) +updated. They can be updated using the @command{mkheaders} script +installed in +@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. @item -On some systems, in particular SunOS 4, header file directories contain +On some systems, header file directories contain machine-specific symbolic links in certain places. This makes it possible to share most of the header files among hosts running the -same version of SunOS 4 on different machine models. +same version of the system on different machine models. The programs that fix the header files do not understand this special way of using symbolic links; therefore, the directory of fixed header files is good only for the machine model used to build it. -In SunOS 4, only programs that look inside the kernel will notice the -difference between machine models. Therefore, for most purposes, you -need not be concerned about this. - It is possible to make separate sets of fixed header files for the different machine models, and arrange a structure of symbolic links so as to use the proper set, but you'll have to do this by hand. - -@item -On Lynxos, GCC by default does not fix the header files. This is -because bugs in the shell cause the @code{fixincludes} script to fail. - -This means you will encounter problems due to bugs in the system header -files. It may be no comfort that they aren't GCC's fault, but it -does mean that there's nothing for us to do about them. @end itemize @node Standard Libraries @@ -796,11 +627,9 @@ scripts adapt to various systems by searching all the system header files for the problem cases that we know about. If new system header files are installed, nothing automatically arranges -to update the corrected header files. You will have to reinstall GCC -to fix the new header files. More specifically, go to the build -directory and delete the files @file{stmp-fixinc} and -@file{stmp-headers}, and the subdirectory @code{include}; then do -@samp{make install} again. +to update the corrected header files. They can be updated using the +@command{mkheaders} script installed in +@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}. @item @cindex floating point precision -- 2.30.2