Need advice for updating OpenGL package

Andre Bleau bleau@igb.umontreal.ca
Tue Feb 25 16:47:00 GMT 2003


Hi there.

I have begun working on an updated OpenGL package. That package is a 
strange beast, so I guess it's time to tidy-up things, and maybe split it 
in a few new packages. I'd like to receive some feedback from the Cygwin 
community before proceeding.


Context:

The purpose of that package was to allow one to build native, OpenGL 
applications. By native, I mean that the display is managed by M$ Windows, 
not by an X server. Some higher-level graphic functions are packaged in GLU 
(GL Utility library). Portable graphic applications are often built around 
OpenGL and GLUT (the GL Utility Tool kit), GLUT being used to open windows, 
obtain graphical rendering contexts, and interact with the user through 
keyboard and mouse in a portable way. Portable widgets libraries, such as 
GLUI and GLUIX, use OpenGL and GLUT as base libraries.

Here in Montreal, we have hundreds of students learning computer graphics 
with combinations of OpenGL, GLU, GLU, and GLUI. Some work with M$ VC++, 
but many use Cygwin and gcc/g++, because it's a good development platform, 
and it's free.


History:

M$ provides opengl32.dll and glu32.dll with every operating system since 
Windows 98. Versions for Windows 95 are downloadable for free. The version 
of OpenGL supported by opengl32.dll is 1.1, dating from 1999. Access to 
more recent functionality (1,2, 1.3, 1.4) is only available through 
"extensions", dynamically loaded from the graphic card driver; more about 
extensions later.

Cygwin initially (before 2000) provided only import libraries for the 
OpenGL, GLU and GLUT DLLs. No headers; and, since the DLLs use the stdcall 
calling convention, which is not the default for gcc, headers obtained on 
the net needed to be modified. The GLUT dll was not included and, being not 
provided by M$ either, had to be downloaded separately from Cygwin.

So the first OpenGL package I provided contained only the missing pieces: 
/usr/include/GL/{gl.h,glu.h,glut.h} and /usr/bin/glut32.dll. So, from the 
start, headers and import libraries have been provided in different 
packages. They still are: the import libraries are currently in the w32api 
package.

Later, as some people wanted to build non-Cygwin programs, I added a link 
from /usr/include/mingw/GL to /usr/include/GL. I also added GLUI and GLUIX, 
static C++ libraries, with their headers, in Cygwin and Mingw versions.


What I want to update in the coming OpenGL package(s):

- OpenGL headers version 1.4, GLU headers version 1.3, along with an up to 
date glext.h.

- The extgl library that facilitates the use of 1.2+ functions through 
extensions.

- Some doc about how to use extensions.

- Updating the GLUT DLL from 3.7.3 to 3.7.6.


Problems:

Since version 1.4-2, the w32api package has begun to include GL headers; 
these hide the ones from the OpenGL package. I reported this in: 
http://sources.redhat.com/ml/cygwin/2002-05/msg01528.html , asking 
cygwiners which package should contain these headers. I received no answer.

People that only want to run a GLUT application under Cygwin need to 
download the OpenGL package, which is rather developer-oriented, just to 
get the GLUT dll. Maybe it's time for a GLUT-runtime package, containing 
just that.

With gcc 3, the include directories searched have changed. With gcc 2, it 
was /usr/include for -mcygwin and /usr/include/mingw for -mno-cygwin. Now, 
/usr/include/w32api is always searched, and files in /usr/include are only 
found if not present in /usr/include/w32api, even with -mcygwin. I thought 
this was wrong and reported it 
(http://sources.redhat.com/ml/cygwin/2003-02/msg01556.html), but, again, no 
answer.

With g++ 3, it seems that name mangling for C++ is different from the one 
used by g++ 2. C++ files compiled with g++ 3 cannot link with the GLUI 
library compiled with g++-2. If I recompile GLUI with g++ 3, C++ files 
compiled with g++-2 cannot link with it. I guess I need to provide both. 
What's the convention in this case? Should they be named libglui.a for g++ 
version 3 and libglui-2.a for g++ version 2?

Is it still OK to provide several libraries in the same package?


Solution 1 to the OpenGL/w32api conflict:

Transfer the import libraries to the OpenGL package. I could generate these 
easily. Zap the OpenGL, GLU and GLUT headers and import libraries from the 
w32api package.


Solution 2 to the OpenGL/w32api conflict:

Transfer the OpenGL, GLU and GLUT headers to the w32api package, even those 
for gcc-2 -mcygwin . I don't feel proprietary about them. I could 
contribute to the w32api package instead of maintaining the OpenGL package. 
Zap the OpenGL package. I could maintain a new GLUT-runtime package 
containing the DLL, and a new GLUI package containing the GLUI and GLUIX 
libraries for developers. This is not my prefered solution, but I could 
live with it.


Please respond to this list. No need to CC me.


André Bleau, Cygwin's OpenGL package maintainer.

email: bleau at igb dot umontreal dot ca
(Fight SPAM: encode your email-address)

Please address all questions and problem reports about Cygwin's OpenGL 
package to cygwin@cygwin.com .



More information about the Cygwin-apps mailing list