Hi Chris,

On Tue, Jul 5, 2011 at 1:21 PM, Chris Barker <Chris.Barker@noaa.gov> wrote:
On 7/4/11 7:58 AM, Alejandro Segovia wrote:
> It seems the binary installer available at the PyOpenGL website is
> dynamically linked against the Visual C++ 7.1 runtime. This library,
> available as the Visual C++ redistributable 2003, is very outdated and
> is kinda hard to obtain nowadays.

from further posts, is seem there may be some PyOpenGL-specific issues
here, but:

As a rule, it is easiest, and maybe necessary, to build python
extensions on Windows with the same version of the MS compiler used to
build the python binary. AFAIK, it's CRT issues.

The binaries on python.org are built with (I think, you'd probably want
to make sure rather than trust my memory)

Python 2.4 -- MSVS 2003
Python 2.5 -- MSVS 2003
Python 2.6 -- MSVS 2008
Python 2.9 -- MSVS 2008

What version of Python (and is it the python.org build?) are you using?

I'm using Python 2.7 on Windows 7 x64. It is the python.org build.
If newer versions of the PyOpenGL binary are built with the 2003 CRT,
then I'm surprised I haven't run into any of these issues yet -- I guess
we've just have that old CRT kicking around on all our machines. Though
aside from having the dll, I wonder if there might be issues with mixing
CRTs in the same binary. I suppose it depends on what you are calling in
the CRT

If you haven't run across this issue, it might be because you have MSVCRT7.1.dll in your system. I do understand you point, however. Perhaps providing a gle32.dll linked against MSVCRT90 could be a problem for people running older versions of Python (2.4 and 2.5).

I have noticed other Python projects usually keep different binary downloads for different versions of Python. Something like that could be adopted for PyOpenGL, where there's a download for Python versions 2.3 and 2.4 with gle32.dll linked against MSVCRT7.1 and another download for newer Python versions, with gle32.dll linked against MSVCRT90.

This is all assuming gle32 is at all needed as a part of PyOpenGL. If it's not used internally, maybe it shouldn't come with PyOpenGL, as the whole linking issue seems to be confusing enough for at least one person :)