signal lists and cpp output

["E. Jay Berkenbilt" <ejb@xxxxxxxxxxx>]

Based on the discussion on the gcc-bugs list over my bug report, it
seems quite compelling that zsh should not be relying on cpp output to
figure out which header file to use for the signal list.  I've been
depending upon cpp output for years for dependency generation where
other options are tricky (because of #includes that are conditional
upon symbols defined by the compiler that only cpp knows about), but
in this case, a simple script that looks through every file mentioned
in any #include directive (recursively) even if it ignores
preprocessor symbols may work and would then separate the zsh autoconf
code from depending upon cpp output.  Alternatively, the zsh autoconf
code could detect the case where it didn't find any signals and fail.

As it happens, this "problem" (which some of the gcc people don't even
think is a bug) does not exist in the current development versions of
gcc.  It is only because RedHat botched up and included a development
version of gcc with 7.0 that this even becomes a problem.  (The
problem is much deeper than this -- there are object file
incompatibilities between gcc 2.96 and both earlier and later versions
-- RedHat had no business including 2.96 with a release even if they
do own Cygnus now....)  Regardless of where the bug/mistakes are, the
fact is though that lots of users are probably going to run into this
problem since RedHat 7.0 will certainly have a wide install base.  (I
am thinking of switching to Debian myself, and for now, I've reverted
back to 6.2 since the gcc/libraries in 7.0 can't deal with my C++
multithreading library and fails with one or two bogus error messages
in C++ code that is valid.)

                                Jay