*stupid* workaround for cpp bug that breaks zsh on RedHat 7.0

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

With respect to my previous message (zsh-workers/12924) about kill -l
not working because of the configure.in code that looks for the
signal.h file breaking because of what looks like a cpp bug, I sent in
the following bug report to bug-gcc.  I have not found a workaround
right now, and I'm going to spend time on other things.  My personal
workaround so that I could get a working zsh was to add a line:

typedef int xxx_work_around_cpp_bug;

to /usr/include/bits/signum.h.  Yes, I know this is a very stupid and
intolerable workaround, but I have so much else to do that I am not
going to burn more time on this for now.  Hopefully the gcc problem
will get fixed or someone will realize that I'm making a silly mistake
here and set me on the right path.  This cpp bug seems quite insidious
and serious to me.  Loads of dependency generators won't work but
people won't notice easily. :-(

>  With gcc 2.96-20000731 as included with vanilla RedHat Linux 7.0
>  (i386) cpp does not provide # line ... output for include files that
>  don't generate any output.  This is very bad for automatic dependency
>  generators.  Create the following two files:
>  
>  a.h:
>  
>  #define HELLO 1
>  
>  
>  a.c:
>  
>  #include "a.h"
>  
>  
>  Then run cpp a.c
>  
>  With an older version you get
>  
>  # 1 "a.c"
>  # 1 "a.h" 1
>  
>  # 1 "a.c" 2
>  
>  
>  
>  With 2.96, you get
>  
>  # 1 "a.c"
>  
>  
>  
>  It appears that cpp is deciding that it doesn't have to generate the #
>  line output if there is no output from the file.  This makes sense for
>  the intend use of these directives for telling the compiler what
>  filename/line number a line of cpp output came from, but it badly
>  hoses dependency generators and other programs that rely on this
>  output for getting a list of files that cpp read.  Such functionality
>  is essential for writing portable dependency generators.  I feel like
>  I've read this in the ISO standard but I can't seem to find any
>  documentation that firmly states that ISO requires this behavior.