From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6436 invoked from network); 8 Oct 2000 19:38:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Oct 2000 19:38:37 -0000 Received: (qmail 29432 invoked by alias); 8 Oct 2000 19:38:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12927 Received: (qmail 29424 invoked from network); 8 Oct 2000 19:38:30 -0000 Date: Sun, 8 Oct 2000 15:38:32 -0400 Message-Id: <200010081938.e98JcWG24273@soup.ql.org> X-Authentication-Warning: soup.ql.org: ejb set sender to ejb@ql.org using -f From: "E. Jay Berkenbilt" To: zsh-workers@sunsite.auc.dk Subject: *stupid* workaround for cpp bug that breaks zsh on RedHat 7.0 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.