gcc-3.0.3, glibc-2.2.5 and groff-1.17.2 failure to compile groff
Thomas T. Veldhouse
veldy at fuggle.veldy.net
Wed Feb 6 19:05:23 PST 2002
On Thu, 7 Feb 2002, [iso-8859-1] Björn Lindberg wrote:
> I'm sorry, from the tone of your first post I assumed that you didn't
> quite understand the original problem. Anyway, the
> /usr/share/bison/bison.simple is a file included by bison itself, so
> it's not a hack.
I disagree for one reason. Bison parses the target file, in this case a
groff source file, and puts an include (or equivalent) in it to directly
point to /usr/share/bison/bison.simple. That is why I said it was a hack.
The original yacc (BSD) certainly does not do this, but instead parses as
> I agree that bison maybe is overly strict when it assumes that if the
> source file is C++, it should look for the definition of size_t in the
> std namespace. However, since the groff source file is a C++ file it
> should include the C++ variants of the standard C header files. In
> <cstdlib> size_t is defined both in and outside of namespace std.
Yes, this is the proper fix for groff, however, it seems to me that bison
emulating yacc is still based upon a hack.
> In short, groff was wrong, bison was right, and I think my solution of
> changing two characters in a source line (easy to make as a patch, which
> I think I did, BTW) is both easier and more correct than to download an
> additional package.
I don't believe bison is correct at all. For one thing, there is not
requirement that one who uses C++ must also use the C++ standard library.
You are free to use the C library or any library you want.
veldy at veldy.net
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev