[HOpenGL] Re: OpenGL/GLUT examples crashing: known problem?

[Claus Reinke]

-------------------- 1. opengl tracers

> Even though I'm not experienced with it, GLinterceptor looks good and 
> works on Windows.
> http://glintercept.nutty.org/

thanks! they don't list win98, but this one does actually seem to work. 

before, I had tried two or three other products, with limited success 
(best was gltrace itself, but that fails to produce a log for me, even 
though it manages to count the calls... strange).

didn't help me much in this case, though, as tess.c crashes before 
producing any log entries..

-------------------- 2. tess (and most likely all gl/glu code that uses 
    callbacks on windows, at least on windows 98 with cygwin/mingw)

made some progress anyway:

- tess.c from the sample link Patrick gave crashes as well, so it doesn't
    seem to be a HOpenGL problem (at least not directly, pls read on)

- I also tried the most recent sample bundle (ftp://ftp.sgi.com/opengl),
    for the fourth edition, same effect

- the README for the bundle mentions the need for the CALLBACK 
    macro:

   "Several programs use callback functions.  The method of casting
    those callback functions worked fine on UNIX based systems, but
    not on PCs.  The programs quadric.c, surface.c, trim.c, tess.c,
    and tesswind.c have been modified.  References to (GLvoid (*))
    cast have been removed, and a reference to the CALLBACK type 
    has been added to the declaration of the callback functions.
    Where CALLBACK is undefined (for instance, in UNIX systems),
    it is stubbed out by use of #ifndef."

- unfortunately, the include files for cygwin/mingw are currently 
    organized in such a way as to undefine CALLBACK on exit, so
    when I compile tess.c (with CC=gcc -mwindows -mno-cygwin),
    all the examples using CALLBACK define it as empty (check
    with gcc -E). This actually leads to comilation warnings about
    passing the callbacks at incompatible types, and then to 
    segmentation faults at runtime. it just so happens that tess
    and tesswind are the two examples that use glu callbacks for
    non-error-recording purposes - I assume some more examples
    would crash if any errors occured and the error-callbacks were 
    to be used.

- replacing the CALLBACK definition in tess.c by the one that
    was in place in the include files before undefinition (compare
    the typedef for _GLUfuncptr in the gcc -E output) cures the
    problem and allows me to compile and run tess without errors
    or crashes.

#ifndef CALLBACK 
#  define CALLBACK __attribute__ ((__stdcall__))
#endif

    note: this may well be different for post-win98 windows systems,
    so the "right" way would be to bring the examples and the cygwin/
    mingw include files back in sync. don't yet know where to report 
    this.. bug reporting experience anyone?

-------------------- 3. so far, so good. 

    but since the HOpenGL version also crashes for the same two 
    examples, I assume that someone got compilation warnings about 
    incompatible type conversions when building the HOpenGL 
    package for windows and didn't notice them, or that the 
    CALLBACK types for different windows versions differ and I 
    get these crashes because I'm compiling the examples on
    win98 whereas the package was most likely built on winxp..?

    of course, that's just a guess, and it could be something else,
    but it isn't a driver problem, and HOpenGL is affected by it.

Could anyone please punch a hole into this, or confirm my guess?
HOpenGL-FFI-mingw experience, anyone?-)

Claus

--
C - the portable assembly debugging target