Re: GDB13 fails to build on MacOS using supplied GNU Bison 2.3

On 8/19/23 20:11, Torbjorn SVENSSON via Gdb wrote:
> Hello,
> 
> I'm trying to build GDB13 for arm-none-eabi on MacOS and have some mixed 
> results.
> It looks like after b2bc564fe817f857b4915903f16026472acfbdcc got merged, 
> the Bison version included in least Mojave, Catalina and Ventura is 
> having trouble to generate code that can be compiled.
> 
> Snippet of the build error:
> 
>        YACC   m2-exp.c
>        CXX    m2-exp.o
>      In file included from .../gdb/m2-exp.y:42:
>      In file included from .../gdb/language.h:26:
>      In file included from .../gdb/symtab.h:39:
>      .../gdb/split-name.h:34:3: error: expected identifier
>        DOT,
>        ^
>      m2-exp.c:163:13: note: expanded from macro 'DOT'
>      #define DOT 302
>                  ^
>      In file included from .../gdb/m2-exp.y:42:
>      In file included from .../gdb/language.h:26:
>      .../gdb/symtab.h:307:23: error: expected unqualified-id
>              style = split_style::DOT;
>                                   ^
>      m2-exp.c:163:13: note: expanded from macro 'DOT'
>      #define DOT 302
>                  ^
>      2 errors generated.
> 
> 

Filed earlier here ( 
https://sourceware.org/bugzilla/show_bug.cgi?id=30286 ).

Thanks,
- Tom

> All three versions of MacOS includes GNU Bison 2.3 and it appears that 
> this issue was fixed in GNU Bison 2.4.
> 
> The change between GNU Bison 2.3 and 2.4 for the m2-exp.c file is that 
> the include statements are placed before the list of token kinds (define 
> statements, including the define for DOT that is used in an enum 
> definition in symtab.h).
> 
> 
> Looking at the binutils tree, I see that sub-directory gprofng contains 
> bison.m4 and a check to confirm that at least version 3.0.4 is available.
> 
> I think the bison.m4 file should be moved up one level and used in both 
> gprofng and gdb, but I'm unable to re-generate the configure scripts.
> 
> Can someone with knowledge of how automake works fix this?
> 
> (CC'ing you Tom as you were the one introducing the split-name.h file 
> that highlights this flaw.)
>