This is the mail archive of the
mailing list for the Cygwin project.
Re: Future of OpenGL package (Earnie, please read this)
- From: Brian Ford <ford at vss dot fsi dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 1 Oct 2003 11:02:09 -0500 (CDT)
- Subject: Re: Future of OpenGL package (Earnie, please read this)
Andre Bleau wrote:
>Igor Pechtchanski wrote:
>>Andre Bleau wrote:
>>>Even, with 1.4 headers, you would sill need to jump through hoops to use
>>>1.4 functionality. You will still need to load the functions dynamicaly
>>>before using them. You wouldn't be able to simply call the functions as
>>>when developing for UNIX.
>>Cygwin DLL uses the autoload functionality for some of the required
>>functions, so that they can simply be called after a test (i.e.,
>>Perhaps this could be employed in the OpenGL library layer as well... I
>>don't know enough off-hand about the autoloading process, but there is a
>>fairly detailed description in winsup/cygwin/how-autoload-works.txt in
>>the Cygwin sources. Might be worth investigating...
>Well, that's exactly what packages like extgl provide: an easier way to
>test if some functionality is available, and if it is, to load it and use
>I was thinking of including extgl in the next major release of the OpenGL
>However, porting UNIX program that uses GL 1.2+ functions would still be
>a pain, although a somewhat lower pain. Say you have a UNIX program with a
>line like this:
I think you missed the point here. On UNIX, a test is already required
to check the OpenGL version or if the extension is supported; assuming
the application programmer "did the right thing." So, no new tests are
required. And, Igor's suggested method is completely dynamic and
transparent, just like UNIX. extgl requires code modifications, all be it
simple ones. What am I missing?
>>> - Have GLUI and GLUIX libs compiled for gcc 3.3
>>You will probably also need to release the old libraries as
>>compatibility packages for those who still use the pre-gcc-3.3 OpenGL
>So, you suggest that I provide:
>libglui.a and libgluix.a for the last version of gcclibglui-gcc3_2.a and
>libgluix-gcc3_2.a for gcc 3.2
>libglui-gcc2_95.a and libgluix-gcc2_95.a for gcc 2.95
>None would be bigger than 500k, so the package would still be manageable.
No. I think that would only be necessary if they were DLLs. I think Igor
was confused. Notice that he said "pre-gcc-3.3 OpenGL binaries" not
>After the long silence that followed my last posting to cygwin-apps about
>these issues, it's good to receive some feedback. Thanks Igor and Brian.
I hope my feedback is still useful, not frustrating. I have a bad and
unintentional habit of being too argumentative here or something.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html