#114 build failure on Arch Linux

[jdtournier]

Hi,

I'm having trouble compiling the file build/gcc_gcc_gl_glx_x11_posix_release/budgielib/tables.c, I get a lot of errors related to an undefined macro for BUGLE_PRIu0, BUGLE_PRId0, etc. These macros seem to be defined in src/platform/posix/platform/types.h (and other platforms too), but not for the BUGLE_PRI*0 versions. I see the problematic file is auto-generated by functions in budgie.cpp, maybe these BUGLE_PRI*0 versions shouldn't exist...? I tried to follow the logic in there, but got a bit lost... Would it be simply a matter of identifying those with zero size in dumpable() and returning false in that case...?

This is using a relatively up to date Arch Linux 64-bit install, using GCC 5.1.0. I've attached the full output of scons for reference, along with the problematic tables.c file itself.

Thanks,
Donald.

[Bruce Merry]

I'm afraid BuGLe doesn't have a maintainer anymore - I've lost interest since I no longer use OpenGL day-to-day. If you do figure out what's going on I'm happy to commit a patch.

It looks like budgie has failed to figure out the actual sizes (in bits) of the types, and is substituting in zeros. That's most likely because the format in which GCC dumps the translation unit has changed and the parsing code in budgie needs to be modified to handle it (this happens every few versions of GCC; if I was still maintaining it, I'd eventually look into using libclang instead). Have a look into build/*/data/gl.tu.

For example, here's what the first few lines look like from GCC 4.8:

@1      type_decl        name: @2       type: @3       chain: @4      
@2      identifier_node  strg: int      lngt: 3       
@3      integer_type     name: @1       size: @5       algn: 32      
                         prec: 32       sign: signed   min : @6      
                         max : @7      
@4      type_decl        name: @8       type: @9       chain: @10     
@5      integer_cst      type: @11      low : 32

So the type name given by node @1 is called "int" (@2), has the type given in @3, and this in turn points to node @5 for its size (32).

[jdtournier]

That's a shame, it's a neat tool. Anyway, you were spot on, it seems the format has changed slightly. Here's what I have:

@1      type_decl        name: @2       type: @3       chain: @4      
@2      identifier_node  strg: int      lngt: 3       
@3      integer_type     name: @1       size: @5       algn: 32      
                         prec: 32       sign: signed   min : @6      
                         max : @7      
@4      type_decl        name: @8       type: @9       chain: @10     
@5      integer_cst      type: @11     int: 32
@6      integer_cst      type: @3      int: -2147483648
@7      integer_cst      type: @3      int: 2147483647
...

Note the int: entries where there used to be low :.

Easy fix - although it took me a little while to get me head around flex... Here's the diff:

*** src/budgie/tulexer.ll.backup        2015-06-26 00:37:25.499033158 +0100
--- src/budgie/tulexer.ll       2015-06-26 00:37:51.098958888 +0100
***************
*** 150,155 ****
--- 150,156 ----

  "lngt: "{DIGIT}+        { yylnode->length = atoi(yytext + 6); }
  "prec: "{DIGIT}+        { yylnode->prec = atoi(yytext + 6); }
+ "int: "-?{DIGIT}+      { yylnode->low = atoi(yytext + 5); }
  "low : "-?{DIGIT}+      { yylnode->low = atoi(yytext + 6); }
  "high: "-?{DIGIT}+      { yylnode->high = atoi(yytext + 6); }

Compile fine now on GCC 5.1 - although there were a few warnings (mostly about unused functions).

Thanks!
Donald.

[Bruce Merry]

Glad it is such as easy fix. I've committed it to the BuGLe repository. When I get some free time I'll roll out another release - there are some other bug fixes that I see are in svn but never got released.

[jdtournier]

Good to hear. On that note, I just went and tried the SVN version: it all works fine too (once I'd figured out I needed to have the docbook tools and yacc installed...).
Thanks!