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

closed-fixed
nobody
None
5
2008-07-11
2008-07-01
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.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks