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.

Tom Veldhouse
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 mailing list