[ Return to Bugs & Features | Roadmap 1.1 ]
|Status:||1 - Closed w/Resolution|
|Priority:||2 - Low, e.g. a documentation error or undocumented side-effect|
|Scope:||3 - Applies to all machines and operating systems|
|Summary:||FreeGLUT no longer works with FLTK GLUT emulation|
|Fix Version:||1.1-current (SVN: v5650)|
Trouble Report Files:
Trouble Report Comments:
12:16 Nov 30, 2006
|See below |
same problem here using FLTK 1.1.7, freeglut and Linux.
Is there any way to solve this issue?
> As most Linux distributions appear to be switching to freeglut as
> a replacement for Mark Kilgard's original GLUT, I have come across
> a compatibility problem between FLTK's implementation and the current
> freeglut-2.4. With earlier versions of freeglut, it was trivially possible to use GLUT functions like glutSolidSphere (or more importantly glutStrokeCharacter) that have no counterparts in FLTK's emulation by simply linking libglut.
> The current 2.4 release of freeglut, however, has introduced an
> internal state variable that is set by its own glutInit() precisely
> to track if glutInit() has been called, and all its functions will
> abort with a fatal error message when they do not find fgState.Initialised == 1. For most other (non-fltk-based) projects, this is probably not much of an issue, as they did forgot to call glutInit() in the first place, so they have a bug in their own code
> to fix.
> With FLTK providing its own replacement, i am not sure how to solve
> this issue - i am currently using an ugly hack in my own code to
> overwrite freeglut's supposedly private fgState structure, but it
> might be necessary to at least document this unexpected incompatibility.
12:38 Nov 30, 2006
|Reassigned to 1.1.x and updated the summary to be more clear. |
Basically, we need to add the remaining GLUT drawing functions to FLTK so that FLTK can act as a replacement for GLUT/FreeGLUT. At the very least we can add the shape functions, but since the FreeGLUT code is provided under the X license there is no reason we can't bundle all of the needed stuff into FLTK's fltk_gl library.
06:48 Dec 05, 2006
|Hi, I'm also working with FreeGLUT and expanding FLTK's GLUT emulation layer. |
This is a change from original GLUT, and since FreeGLUT's goal is to be a 100% compatible/complete replacement of GLUT, this may be fixed in FreeGLUT.
I don't see any need for state initialization in geometry functions, so this is just a picky assertion. Please submit this issue to the FreeGLUT mailing list (I can do it if you don't wish to subscribe).
09:08 Dec 05, 2006
|The freeglut people appear to think of it as a feature - in fact the |
resulting incompatibility is mentioned in the release announcement of
BTW I am the original author of the message quoted in the STR - the
workaround I mentioned there is not an ideal solution, as
we can no longer link dynamically against whatever glut is available,
since none of the other implementations of GLUT define the struct that
my hack overwrites.
Importing enough of the GLUT headers to find a tell-tale version string
to compare against at runtime appears to be impossible as well, as this
would lead to tons of duplicate definitions.
04:37 Dec 20, 2006
|Will probably be fixed in the next FreeGLUT: |
07:38 Jan 21, 2007
|Can we assume that this is fixed in FreeGLUT? Or, Mike, will you be adding new GLUT code? Before 1.1.8 or possibly after a release? ||
16:28 Jan 21, 2007
|I'd actually like to add the FreeGLUT code to FLTK; I've always felt "dirty" telling people to link to two "GLUT" libraries... ||
10:12 Feb 01, 2007
|Added all of the geometry and text functions, plus glutExtensionPresent(), glutDeviceGet(), and some other miscellaneous functions we can safely support. |
Please open new STRs for any functions that are missing that we can support.
11:01 Feb 01, 2007
[ Return to Bugs & Features ]