On Tue, Jul 5, 2011 at 1:21 PM, Chris Barker <Chris.Barker@...> 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 :)