Advice sought: recommendation for maintainers for new bison and old gcc

[Mike Castle]

I finally solved an issue today that popped up it's head with bison 1.49a,
and I come here to seek advice on what to really do.

In my situation, I was trying to build Gnome's libIDL-0.8.0 with a new
bison but an old gcc.  Now, as I typically do with autoconfed packages, I
build in a separate build directory (mostly to keep developers honest with
respect to the GNU Coding standards :-).

What was happening was that the libIDL I built failed when later being used
to build ORBit-2.4.3.

It turned out that gcc (gcc version 2.95.4 20020723 (prerelease)) will
change the include path when it sees a #line.  As a result, it was picking
up the parser.h that came shipped with libIDL rather than the one that
bison just produced.  Picking up the wrong include file is dangerous at any
time, but more so now that the TOK_* tables are slightly different.

Now, with gcc-3, #line no longer changes the include path (see
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=5153 for
spirited discussions on whether #line doing that is a bug or not :-).

Someone using the latest bison and not the latest gcc is probably rare.
But imagine where a developer uses recent bison and a user uses an old
bison/gcc pair.  They'll still have the same include file issue.

Now, there are several work arounds.  If using bison, then nuke the
provided header file in srcdir.  Defeats the purpose of being able to build
in a separate build dir, in case srcdir is read only, or to be shared
across platforms (where not all may have bison or equiv).  

So anyway, this is really only a concern if using old gcc, different bison
versions, and building in a separate build directory.  So a project
maintainer really be concerned about this?  Should this be an autoconf
issue where it could detect this particular situation and add -l?  Same
issue with flex.  Actually, in the case I was faced with, it was lexer.c
that was bringing in the wrong parser.h.

So, when I come across this issue with maintainers, what should I recommend
to them as the proper solution?

Thanks,
mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc