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
expected.

> 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