🚀 go-pugleaf

Many operating systems, including SunOS 4, come with system
header files that are incorrect for ANSI C.  Installation of GCC
"fixes" the common problems so that the header files will work right
in ANSI C.

It would not be nice to modify the files in /usr/include--you might
want to use them with some other compiler.  So GCC puts the fixed
header files in another directory, normally somewhere under
/usr/local/lib/gcc-lib.  Normally GCC searches that dir before it
searches /usr/include.

But if you specify a compiler option such as -I/usr/include, that
defeates GCC's efforts to correct the header files.  This leads to
problems such as crashing or hanging on startup (when not using X), or
inability to send signals to subprocesses (when using X).

flee@guardian.cse.psu.edu says:

    A simple test for gcc/fixinclude problems: compile and run the
    following program using gcc and non-gcc.  Both versions should print
    the same value (0x4004667f on SunOS 4.x):

	    #include <sys/ioctl.h>
	    main() {printf("FIONREAD = 0x%08x\n", FIONREAD);}

Of course, to make this a useful test, you have to use the same
compiler options that are actually used when the source files of
Emacs are compiled.

Recent versions of GCC are supposed to install the fixed header files
automatically, and Emacs's configure and makefiles are supposed to use
compilation options that get the fixed header files.  Everything is
supposed to work right automatically.  So if it doesn't work right
automatically, and if you did not do something strange by hand, then
there's a bug in either Emacs or GCC.

If you've encountered such a bug, please localize the problem by
looking at the options that were set up in src/Makefile.  See which
header files GCC should have used, given those options.  (Look at the
GCC manual to see what the options mean.)

If GCC was given reasonable options, which specified a search path for
include files that would find the fixed ones first, and GCC failed to
do so, then the bug is in GCC.  So send a GCC bug report as described
in the GCC manual's Bugs chapter.

If GCC was given options that tell it to look at the unfixed header
files first, then the bug is in Emacs.  In order to fix it, I need to
know the chain of events that leads to the wrong decision.  So please
debug the configure program, and the action of cpp on src/Makefile.in,
to see where and how the wrong decision was made.  Please read the
Bugs chapter of the Emacs 19 manual for additional advice.

(If I had fewer bug reports to handle, I might be able to investigate
these things myself; but I am ovrstretched.  So the problems that get
fixed will be the ones that you investigate.)