This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Preprocessing oddity breaks binutils
- To: Dave Brolley <brolley@cygnus.com>
- Subject: Re: Preprocessing oddity breaks binutils
- From: Zack Weinberg <zack@rabi.columbia.edu>
- Date: Wed, 02 Jun 1999 14:49:53 -0400
- cc: Mark Mitchell <mark@codesourcery.com>, egcs-bugs@egcs.cygnus.com, binutils@sourceware.cygnus.com
On Wed, 02 Jun 1999 12:04:06 -0400, Dave Brolley wrote:
>I agree that this is probably a long standing quirk bug in the
>preprocessor which is arguably a bug. Does anyone know of any source which
>relies on the current behaviour?
FYI, cpplib uses the test.h in the subdirectory. I agree with Mark that
this is the right thing - #line should not affect the search path.
zw
>
>Dave
>
>Mark Mitchell wrote:
>
>> It's impossible to build the current binutils in CVS because of what I
>> think is a bug in the C preprocessor. Consider the following
>> directory layout:
>>
>> linux1.codesourcery.com% ls -lR
>> total 2
>> drwxrwx--x 2 mitchell mitchell 1024 Jun 1 18:54 baz/
>> -rw-rw---- 1 mitchell mitchell 7 Jun 1 18:49 test.h
>>
>> baz:
>> total 1
>> -rw-rw---- 1 mitchell mitchell 38 Jun 1 18:50 test.c
>> -rw-rw---- 1 mitchell mitchell 0 Jun 1 18:49 test.h
>>
>> Suppose that baz/test.h is empty, but that the top-level baz.h
>> contains a #error. Suppose that test.c is:
>>
>> #line 1 "../test.c"
>> #include "test.h"
>>
>> Now, suppose that in baz you run:
>>
>> cpp test.c
>>
>> What happens is:
>>
>> linux1.codesourcery.com% cpp test.c
>> In file included from ../test.c:1:
>> ../test.h:1: #error
>>
>> The standards are pretty obscure about what exactly a #line does, or
>> for that matter, how the include path is searched, but I think this is
>> very confusing behavior. I would never guess, as a user, that what
>> #lines are inserted in a source file would affect where we would
>> search for the file.
>>
>> In the binutils case, what's happening is that a generated lexer (from
>> lex) is being placed in the objdir, along with a a generated include
>> file full of tokens. However, there's *already* a file of tokens in
>> srcdir. When compiling the lexer, we get the old file of tokens,
>> because the lexer contains #line directives referring back to the old
>> lexer.
>>
>> Perhaps, in the interests of portability, some kind of modification to
>> binutils or automake is a good idea as well. (This is happenning with
>> ldlex.l, ldgram.h, and friends in the `ld' subdirectory of binutils.)
>>
>> --
>> Mark Mitchell mark@codesourcery.com
>> CodeSourcery, LLC http://www.codesourcery.com
>
>
>