Compilation error lib.c

Help
2009-05-05
2013-06-13
  • I'm having trouble compiling bugle.

    Error:
    budgielib/lib.c: In function ‘budgie_invoke’:
    budgielib/lib.c:17057: warning: passing argument 3 of ‘(void (*)(GLuint,  GLuint,  GLsizei,  GLsizei *, GLsizei *, GLenum *, GLchar *))budgie_function_address_real(687)’ makes integer from pointer without a cast
    budgielib/lib.c:17057: error: too few arguments to function ‘(void (*)(GLuint,  GLuint,  GLsizei,  GLsizei *, GLsizei *, GLenum *, GLchar *))budgie_function_address_real(687)’
    budgielib/lib.c:17060: warning: passing argument 3 of ‘(void (*)(GLuint,  GLuint,  GLsizei,  GLsizei *, GLsizei *, GLenum *, GLchar *))budgie_function_address_real(688)’ makes integer from pointer without a cast
    budgielib/lib.c:17060: error: too few arguments to function ‘(void (*)(GLuint,  GLuint,  GLsizei,  GLsizei *, GLsizei *, GLenum *, GLchar *))budgie_function_address_real(688)’
    budgielib/lib.c:19349: warning: passing argument 3 of ‘(void (*)(GLuint,  GLsizei,  const GLchar **, GLenum))budgie_function_address_real(1451)’ from incompatible pointer type
    budgielib/lib.c:19352: warning: passing argument 3 of ‘(void (*)(GLuint,  GLsizei,  const GLchar **, GLenum))budgie_function_address_real(1452)’ from incompatible pointer type
    budgielib/lib.c: In function ‘glGetTransformFeedbackVarying’:
    budgielib/lib.c:35548: error: too few arguments to function ‘(void (*)(GLuint,  GLuint,  GLsizei,  GLsizei *, GLsizei *, GLenum *, GLchar *))budgie_function_address_real(687)’
    budgielib/lib.c: In function ‘glGetTransformFeedbackVaryingEXT’:
    budgielib/lib.c:35569: error: too few arguments to function ‘(void (*)(GLuint,  GLuint,  GLsizei,  GLsizei *, GLsizei *, GLenum *, GLchar *))budgie_function_address_real(688)’

    lib.c seems to be generated, and from what I gather it is generated from glew.  So is this a version conflict?

    I have the newest of both on my ubuntu system.  It clearly makes some mistakes here:
    BUDGIE_DLL_EXPORT void BUDGIEAPI glGetTransformFeedbackVaryingEXT(GLuint arg0, GLuint arg1, GLsizei arg2, GLsizei *arg3, GLsizei *arg4, GLenum *arg5, GLchar *arg6)
    {
        function_call call;
        if (_budgie_bypass[FUNC_glGetTransformFeedbackVaryingEXT] || !_budgie_reentrance_init())
        {
            (*(void (* BUDGIEAPI)(GLuint, GLuint, GLsizei, GLsizei *, GLsizei *, GLenum *, GLchar *)) budgie_function_address_real(FUNC_glGetTransformFeedbackVaryingEXT))(arg0, arg1, arg2);
            return;
        }
        call.generic.id = FUNC_glGetTransformFeedbackVaryingEXT;
        call.generic.group = GROUP_glGetTransformFeedbackVaryingEXT;
        call.generic.retn = NULL;
        call.generic.num_args = 3;
        call.generic.args[0] = &arg0;
        call.generic.args[1] = &arg1;
        call.generic.args[2] = &arg2;
        budgie_interceptor(&call);
        _budgie_reentrance_clear();
    }

    It seems that its not parsing the function call correctly: call.generic.num_args is 3, but it seems to think that there is 7.  The actual definition (found in glew.h) is (GLuint, GLuint, GLint*).  The function defined RIGHT BEFORE in glew.h matches the signature (which is glGetActiveVarying (GLuint, GLuint, GLsizei, GLsizei*, GLsizei*, GLenum*, GLchar*)).

    ALL the errors seem to deal with that one function glGetTransformFeedbackVarying, so I suspect it is a glitch in parsing glew.h

    What should I change to fix this, as I am not entirely sure why its making this mistake

     
    • Bruce Merry
      Bruce Merry
      2009-05-06

      Hi. You're half-right: lib.c is generated from glext.h rather than glew.h. It's also generated from the parse tree generated by GCC, so it's unlikely to be an issue with parsing.

      I've just grabbed the latest glext.h and I'm now seeing the same problem on my machine, so I'll dig deeper and see if I can find out what's confusing it. If you can find an older glext.h somewhere you might have some luck.

      Bruce

       
    • Bruce Merry
      Bruce Merry
      2009-05-06

      Ok, it looks like the problem came from glGetTransformFeedbackVarying and glGetTransformFeedbackVaryingNV having different numbers of arguments. The patch below should fix it:

      Index: gengl/gengl.perl

      --- gengl/gengl.perl    (revision 736)
      +++ gengl/gengl.perl    (working copy)
      @@ -175,6 +175,9 @@
           # /usr/include/GL/glxext.h:extern void glXBindSwapBarrierSGIX (Display *, GLXDrawable, int);
           # /usr/include/GL/glxext.h:extern Bool glXBindSwapBarrierNV(Display *dpy, GLuint group, GLuint barrier);
           "glXBindSwapBarrierNV" => 1,
      +
      +    # NV version has only 3 args
      +    "glGetTransformFeedbackVaryingNV" => 1
      );

      # Enumerants that we don't want to be the chosen return for

       
    • Thanks, that fixed it.

       
    • Now, I'm getting this error when trying to stop a program:

      *** %n in writable segment detected ***
      .

      It just crashes and stops.  %n is not allowed in writable segments due to common exploits that use this.  Maybe its my system configuration?

       
      • Bruce Merry
        Bruce Merry
        2009-05-07

        It looks like Ubuntu is configured to turn on some safety checks by default that make the compiler non-conformant. Unfortunately the %n doesn't come from my code, it comes from lib/vasprintf.c which is from Gnulib. I'll put it on my bug list to go and hack this code, but for the moment you can perhaps try adding CFLAGS="-D_FORTIFY_SOURCE=1" to your configure or make command. Let me know if that works for you.

         
    • Thanks! Adding that now allows it to run and inspecting my framebuffers and other opengl state seems to be working.

      I'm getting these warnings, but I'm not using any of these, but just incase you wanted to know about them:
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_LAYERED_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_LAYERED_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LEVEL_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_CUBE_MAP_FACE_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER_EXT
      [WARNING] glstate.get: GL_INVALID_ENUM generated by state GL_FRAMEBUFFER_ATTACHMENT_LAYERED_EXT
      [WARNING] glstate.get: GL_INVALID_VALUE generated by state GL_TRANSFORM_FEEDBACK_RECORD_NV
      [WARNING] glstate.get: GL_INVALID_VALUE generated by state GL_TRANSFORM_FEEDBACK_RECORD_NV
      [WARNING] glstate.get: GL_INVALID_VALUE generated by state GL_TRANSFORM_FEEDBACK_RECORD_NV
      [WARNING] glstate.get: GL_INVALID_VALUE generated by state GL_TRANSFORM_FEEDBACK_RECORD_NV

      Maybe its just my usage though.

       
      • Bruce Merry
        Bruce Merry
        2009-05-07

        Those warnings might mean that I've messed up the state querying code and I'm asking for invalid state. On the other hand, at least half the time that I investigate these kind of warnings it turns out to be a driver bug, so now I tend to just ignore them.