Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#4 Fix-ups to correct GL/GLU lib detection logic

closed-fixed
nobody
None
5
2008-07-11
2008-07-01
coleman kane
No

The m4 macro script in m4/gl.m4 has one serious bug, and a few smaller problems that could be fixed.

First of all, the script erases the value of $with_gl_lib when it performs the Darwin Frameworks check, but unconditionally setting:

with_gl_lib=$FRAMEWORKS_OPENGL

Additionally, when cross-compiling to a Win32 target (using MinGW32, for instance), the opengl32 and glu32 libraries don't use the cdecl calling convention. Rather, they use stdcall which requires that the functions be prototyped properly to build the proper symbol name (Function@ARGBYTES). For example, glBegin(GLint) becomes glBegin@4 (where 4 means 4 arg bytes).

This patch fixes the Darwin Frameworks problem by only assigning the value of $FRAMEWORKS_OPENGL if the frameworks were detected.

Additionally, the patch modifies the link check so that if it fails to link against the dummy prototype, it will subsequently attempt to link a version that #include's the GL/gl.h or GL/glu.h headers, to see if that succeeds. Only if both checks fail will it set $HAVE_GL to "no".

Discussion

  • coleman kane
    coleman kane
    2008-07-01

    Fix FRAMEWORKS_OPENGL breakage, and make it support Win32 stdcall linking

     
  • Sam Hocevar
    Sam Hocevar
    2008-07-11

    • status: open --> closed-fixed
     
  • Sam Hocevar
    Sam Hocevar
    2008-07-11

    Logged In: YES
    user_id=37415
    Originator: NO

    Thanks for the patch. Applied to HEAD.