From: sct@dcs.ed.ac.uk (Stephen Tweedie) Subject: Re: bug in cpp? Date: 28 Jan 1993 21:16:56 GMT
In article <1993Jan27.192855.9198@serval.net.wsu.edu>, hlu@eecs.wsu.edu (H.J. Lu) writes:
> In article <1993Jan27.105225.3418@athena.mit.edu>, ludger.kunz@fernuni-hagen.de (Ludger Kunz) writes:
> |> Today i tried to compile gzip-0.8.1. Everything worked fine except for
> |> the assembler file. The file match.S is preprocessed by cpp with
> |> the following command:
> |> /lib/cpp -DUNDERLINE match.S > _match.s
It shouldn't. There is a bug (at least an incompatibility) in 0.8.1
which causes this error, but the configure script ought to catch this
and elect to compile without the optional assembly code file.
> |> When trying to compile the _match.s-file with gcc, the following
> |> 2 messages occur:
> |> match.s:51: invalid character '_' in opcode
> |> match.s:63: invalid character '_' in opcode
> |>
> |> Looking at the file _match.s leads to the lines
> |>
> |> _match_init :
> |> and
> |> _longest_match :
> |>
> |> Removing the blank between the label and the colon leads to a successful
> |> compilation.
Indeed. This is a "feature" of the Linux cpp, and one which I am not
sure is correct: cpp inserts spaces after macro expansions. Certainly
the sun cpp does not do this. It also makes it awkward to use cpp to
produce neat human-readable output; you get annoying double spaces
everywhere.
HJ, is this correct behaviour?
> |> Another bug concerns the following code:
> |> add $window+2,%edi
> |> This leads to an error while linking. The symbol window must be replaced with
Yup - the gnu cpp allows '$' in identifiers, so it sees the identifier
"$window" rather than "window", and fails to expand it. I think that
"cpp -$" is supposed to suppress this behaviour.
> For gzip-0.8.1 with gcc 2.3.3 + 0.99.4, I did
> configure
> vi Makefile # remove getopt.o which is in libc.a
> make
Yes, that should work, but it won't link in the fast 386 assembler
code for the reasons above.
I found this bug a couple of days ago, and the gzip maintainer
(Jean-loup Gailly <jloup@fr.chorus>) has fixed it for the next
release, gzip-0.8.2, at an archive site near you now. (He has
basically worked around the Linux cpp incompatibilities by having
identifiers _with_ underscores by default, which Linux likes, and only
running cpp on the file if it is necessary to remove those
underscores: the opposite of the gzip-0.8.1 behaviour.) 0.8.2 also
fixes the buggette which prevents zcatting .z files with multiple hard
links. It's worth upgrading.
Cheers,
Stephen Tweedie.