Preprocessor woes

Preprocessor woes

[Mark Kettenis]

When compiling glibc for the Hurd, during generation of the .map
files, I get the following error messages:

   :1163: parse error
   :1169: parse error
   :1258: parse error
   :1267: parse error
   :1295: parse error
   :1303: parse error
   :1342: parse error

The line numbers are exactly the lines where constructs like

   #if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1)

occur.  Since the SHLIB_COMPAT macro uses the ISO C ## concatenation
operator, -traditional messes things up.  Is there any chance at
convincing the GCC folks to provide a preprocessor that's backwards
compatible with cccp?

Mark

Re: Preprocessor woes

[Neil Booth]

Mark Kettenis wrote:-

> occur.  Since the SHLIB_COMPAT macro uses the ISO C ## concatenation
> operator, -traditional messes things up.  Is there any chance at
> convincing the GCC folks to provide a preprocessor that's backwards
> compatible with cccp?

Try using the portable CONCAT macros that GCC does.  That's much
simpler than rewriting tradcpp (which is what this would require).

Neil.

Re: Preprocessor woes

[Zack Weinberg]

On Fri, Jan 05, 2001 at 09:45:55PM +0000, Neil Booth wrote:
> Mark Kettenis wrote:-
> 
> > occur.  Since the SHLIB_COMPAT macro uses the ISO C ## concatenation
> > operator, -traditional messes things up.  Is there any chance at
> > convincing the GCC folks to provide a preprocessor that's backwards
> > compatible with cccp?
> 
> Try using the portable CONCAT macros that GCC does.  That's much
> simpler than rewriting tradcpp (which is what this would require).

Concatenation with ## has never worked in -traditional mode.  The real
problem is something else.

zw

Re: Preprocessor woes

[Mark Kettenis]

   From: "Zack Weinberg" <zackw@stanford.edu>
   Date: Fri, 5 Jan 2001 14:40:26 -0800

   On Fri, Jan 05, 2001 at 09:45:55PM +0000, Neil Booth wrote:
   > Mark Kettenis wrote:-
   > 
   > > occur.  Since the SHLIB_COMPAT macro uses the ISO C ## concatenation
   > > operator, -traditional messes things up.  Is there any chance at
   > > convincing the GCC folks to provide a preprocessor that's backwards
   > > compatible with cccp?
   > 
   > Try using the portable CONCAT macros that GCC does.  That's much
   > simpler than rewriting tradcpp (which is what this would require).

   Concatenation with ## has never worked in -traditional mode.  The real
   problem is something else.

We used to preprocess this stuff without -traditional.  Then the new
preprocessor introduced some whitespace in funny places; see
< http://sources.redhat.com/ml/libc-alpha/2000-11/msg00262.html >.  Then
Ulrich switched to -traditional (I think after a suggestion from you
or Neil).  And now the Hurd doesn't build anymore :-(.

I cc'd you GCC folks to make you aware that the new preprocessor is
causing some real pain, and I saw no way out.  Fortunately there are
at least two workarounds (thanks Neil and Jakub).  I still think it
would be better if the new integrated preprocessor would be backwards
compatible with the old one, even for sources that are not C.

Mark

Re: Preprocessor woes

[Richard Henderson]

On Sat, Jan 06, 2001 at 12:39:02AM +0100, Mark Kettenis wrote:
> I still think it would be better if the new integrated preprocessor
> would be backwards compatible with the old one, even for sources that
> are not C.

Try -xassembler-with-cpp.  I believe many of the whitespace
issues go away then.


r~

Re: Preprocessor woes

[Joe Buck]

> I cc'd you GCC folks to make you aware that the new preprocessor is
> causing some real pain, and I saw no way out.  Fortunately there are
> at least two workarounds (thanks Neil and Jakub).  I still think it
> would be better if the new integrated preprocessor would be backwards
> compatible with the old one, even for sources that are not C.

The integrated preprocessor is intended for use only with C, C++ or
Objective-C, because in its normal mode the lexing for the preprocessor
and the compiler are combined.  There are no longer two separate programs
communicating with each other via file or pipe.  (If you ask for the
output, you do get text, but it is somewhat artificial in that the
compiler never normally reads this text).

I've supported efforts to keep -traditional traditional (that is, suitable
for all the non-C uses it's currently being put to), including beating
Zack up perhaps a bit too strongly when he objected.  But I'll only take
that battle so far.  If you want to process text that is not C (or C++ or
Objective-C), use -traditional; without -traditional there is no promise
of consistent behavior for input that is not ISO C.  Demanding complete
consistency on non-standard input is an impossibly difficult task for a
completely new implementation.

We'll be happy to help people who are having problems with this fix their
software or come up with other workarounds.