Thread: [PyOpenGL-Users] PyOpenGL on Windows
Brought to you by:
mcfletch
From: Alejandro S. <as...@gm...> - 2011-07-04 14:58:45
|
Hello all, As some of you might know, I've been a PyOpenGL user since 2006, however, today I'm attempting to use PyOpenGL on Windows for the very first time in my life and I'm experiencing a dependencies issue. 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. I tried building PyOpenGL from source and the produced package seems to depend on the 7.1 runtime as well. As a consequence, I have two questions someone might be able to help me with: 1. Why is the Visual C++ 7.1 runtime a dependency even when I build from source and I don't have the VC7.1 compiler? 2. I have a VS10 compiler available, would anyone be interested in me building a more recent binary release for Windows? I can do it, but I'm going to need some help regarding how to get rid of the old 7.1 runtime. Thanks in advance. Best regards, Alejandro.- -- http://alejandrosegovia.net |
From: Henry G. <he...@ca...> - 2011-07-04 15:04:35
|
On Mon, 2011-07-04 at 11:58 -0300, Alejandro Segovia wrote: > today I'm attempting to use PyOpenGL on Windows for the very first > time in my life I, too, am very interested in doing this shortly, so I second the questions! Cheers, Henry |
From: Alejandro S. <as...@gm...> - 2011-07-04 16:43:37
|
It seems this issue has been brought up before, although on a slightly different form. There was an email thread at [1] and there even seems to be an open ticket regarding this at [2]. I can confirm that after getting the MSVCRT7.1.dll not found error message every time I lunch my application, it happens to run fine, with all OpenGL code working. I guess the two questions stand though, does anyone know why we might be getting this message? Alejandro.- References: [1] - http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimctcemkdkY4U4JyX9EibLj01ERgNhBXPbrC-Rq%40mail.gmail.com&forum_name=pyopengl-users [2] - http://sourceforge.net/tracker/index.php?func=detail&aid=3177110&group_id=5988&atid=105988 On Mon, Jul 4, 2011 at 12:04 PM, Henry Gomersall <he...@ca...> wrote: > On Mon, 2011-07-04 at 11:58 -0300, Alejandro Segovia wrote: > > today I'm attempting to use PyOpenGL on Windows for the very first > > time in my life > > I, too, am very interested in doing this shortly, so I second the > questions! > > Cheers, > > Henry > > -- http://alejandrosegovia.net |
From: Henry G. <he...@ca...> - 2011-07-04 17:33:02
|
On Mon, 2011-07-04 at 13:43 -0300, Alejandro Segovia wrote: > I can confirm that after getting the MSVCRT7.1.dll not found error > message every time I lunch my application, it happens to run fine, > with all OpenGL code working. It seems that the gle32.dll packaged with PyOpenGL has this dependency, so its this library that needs to be recompiled. I've just spent a little while trying to hunt the source down for that library, and the best I get to is here: http://linas.org/mirrors/www.quiknet.com/2001.04.09/~moriarty/downloads.htm but the source link (look inside the html) is dead. If you try to go to that quicknet page, it redirects to surewest.com. Someone must have the source somewhere! (it's GPL according to the license file). cheers, Henry |
From: Henry G. <he...@ca...> - 2011-07-04 17:49:47
|
On Mon, 2011-07-04 at 18:32 +0100, Henry Gomersall wrote: > On Mon, 2011-07-04 at 13:43 -0300, Alejandro Segovia wrote: > > I can confirm that after getting the MSVCRT7.1.dll not found error > > message every time I lunch my application, it happens to run fine, > > with all OpenGL code working. > > It seems that the gle32.dll packaged with PyOpenGL has this > dependency, > so its this library that needs to be recompiled. My naive fiddling seems to suggest a fairly minimal dependency on MSVCR71.dll. winedump shows the following symbols. Most of those look like they won't have changed much (although some look like they might have!)... offset 0001e1dc MSVCR71.dll Hint/Name Table: 0001E23C TimeDateStamp: 00000000 (Thu Jan 1 01:00:00 1970) ForwarderChain: 00000000 First thunk RVA: 0001E024 Ordn Name 766 sin 1e3dc 241 _except_handler3 1e456 76 __CppXcptFilter 1e444 187 _adjust_fdiv 1e434 319 _initterm 1e428 440 _onexit 1e412 107 __dllonexit 1e404 648 atan2 1e3fc 757 realloc 1e3f2 644 acos 1e3ea 769 sqrt 1e3bc 684 free 1e3c4 735 malloc 1e3cc 658 cos 1e3d6 665 fabs 1e3e2 Interesting discussion here on CRT versioning... http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ Cheers, Henry |
From: Henry G. <he...@ca...> - 2011-07-04 18:05:52
|
On Mon, 2011-07-04 at 18:32 +0100, Henry Gomersall wrote: > It seems that the gle32.dll packaged with PyOpenGL has this > dependency, > so its this library that needs to be recompiled. It also seems to be a fairly minimal change to remove the GLE functionality entirely under Windows. Certainly, I won't be needing it. Cheers, Henry |
From: Alejandro S. <as...@gm...> - 2011-07-04 18:15:53
|
Hi Henry, Thanks for all the help. The CRT versioning discussion was a great read. >> It seems that the gle32.dll packaged with PyOpenGL has this > >> dependency, so its this library that needs to be recompiled. > > It also seems to be a fairly minimal change to remove the GLE > functionality entirely under Windows. Certainly, I won't be needing it. > Yes, I think I'll go this way too. I'll try to find whatever code requests this DLL to be loaded and nuke it. I just hope nothing breaks. It would still be nice being able to recompile this library and patch PyOpenGL. I found this other page using Google: http://brightideassoftware.com/GLE32Downloads.aspx but the source code is incomplete and I can't build it. If anyone has the GLE32 code, please drop me a line. Best, Alejandro.- -- http://alejandrosegovia.net |
From: Alejandro S. <as...@gm...> - 2011-07-04 18:41:44
|
Okay guys, I managed to get the GLE source code. It was found laying in a SourceForge project. http://sourceforge.net/projects/gle/ By default it builds as a static library. I ported the project to Visual C++ 9 (so it links against MSVCRT9.0) and tweaked it to build into a DLL file. I've replaced the old and busted gle32.dll with this new DLL and my application no longer complains about missing the MSVCRT7.1 runtime. Mike, would you agree on replacing the old DLL in the PyOpenGL source bundle with this one? Best, Alejandro.- On Mon, Jul 4, 2011 at 3:15 PM, Alejandro Segovia <as...@gm...> wrote: > Hi Henry, > > Thanks for all the help. The CRT versioning discussion was a great read. > > >> It seems that the gle32.dll packaged with PyOpenGL has this >> >> dependency, so its this library that needs to be recompiled. >> >> It also seems to be a fairly minimal change to remove the GLE >> functionality entirely under Windows. Certainly, I won't be needing it. >> > > Yes, I think I'll go this way too. I'll try to find whatever code requests > this DLL to be loaded and nuke it. I just hope nothing breaks. > > It would still be nice being able to recompile this library and patch > PyOpenGL. I found this other page using Google: > http://brightideassoftware.com/GLE32Downloads.aspx but the source code is > incomplete and I can't build it. > > If anyone has the GLE32 code, please drop me a line. > > Best, > Alejandro.- > > > -- > http://alejandrosegovia.net > > -- http://alejandrosegovia.net |
From: Chris B. <Chr...@no...> - 2011-07-05 16:21:21
|
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? 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 HTH, -Chris I tried building PyOpenGL from source > and the produced package seems to depend on the 7.1 runtime as well. > > As a consequence, I have two questions someone might be able to help me > with: > > 1. Why is the Visual C++ 7.1 runtime a dependency even when I build from > source and I don't have the VC7.1 compiler? > > 2. I have a VS10 compiler available, would anyone be interested in me > building a more recent binary release for Windows? I can do it, but I'm > going to need some help regarding how to get rid of the old 7.1 runtime. > > Thanks in advance. > > Best regards, > Alejandro.- > > -- > http://alejandrosegovia.net > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Alejandro S. <as...@gm...> - 2011-07-05 16:54:32
|
Hi Chris, On Tue, Jul 5, 2011 at 1:21 PM, Chris Barker <Chr...@no...> 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 :) Best, Alejandro.- -- http://alejandrosegovia.net |
From: Chris B. <Chr...@no...> - 2011-07-05 17:23:40
|
On 7/5/11 9:54 AM, Alejandro Segovia wrote: > 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. > I'm using Python 2.7 on Windows 7 x64. It is the python.org > <http://python.org> build. then I am surprised that there aren't issues with that older CRT. > If you haven't run across this issue, it might be because you have > MSVCRT7.1.dll in your system. probably do -- it's pretty darn common. I've generally not bothered to distribute it with py2exe projects, as most people have it. (or did -- it maybe getting less common with Win7 systems, etc) > 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). it might, yes - certainly testing would be in order. > I have noticed other Python projects usually keep different binary > downloads for different versions of Python. yes -- that's generally required -- as a rule, the different versions of python are not binary compatible, so you need to do that, CRT issues aside. I guess if you use ctypes as your only interface, you avoid that. > 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 :) indeed -- that would simplify things. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Mike C. F. <mcf...@vr...> - 2011-07-08 02:54:39
|
On 11-07-04 02:41 PM, Alejandro Segovia wrote: > Okay guys, I managed to get the GLE source code. It was found laying > in a SourceForge project. > > http://sourceforge.net/projects/gle/ > > By default it builds as a static library. I ported the project to > Visual C++ 9 (so it links against MSVCRT9.0) and tweaked it to build > into a DLL file. > > I've replaced the old and busted gle32.dll with this new DLL and my > application no longer complains about missing the MSVCRT7.1 runtime. > > Mike, would you agree on replacing the old DLL in the PyOpenGL source > bundle with this one? IIRC we need to have multiple versions and choose the correct one based on which Python we are installing into. I've tagged this as a todo for myself. HTH, Mike > > On Mon, Jul 4, 2011 at 3:15 PM, Alejandro Segovia <as...@gm... > <mailto:as...@gm...>> wrote: > > Hi Henry, > > Thanks for all the help. The CRT versioning discussion was a great > read. > > >> It seems that the gle32.dll packaged with PyOpenGL has this > >> dependency, so its this library that needs to be recompiled. > > It also seems to be a fairly minimal change to remove the GLE > functionality entirely under Windows. Certainly, I won't be > needing it. > > > Yes, I think I'll go this way too. I'll try to find whatever code > requests this DLL to be loaded and nuke it. I just hope nothing > breaks. > > It would still be nice being able to recompile this library and > patch PyOpenGL. I found this other page using > Google: http://brightideassoftware.com/GLE32Downloads.aspx but the > source code is incomplete and I can't build it. > > If anyone has the GLE32 code, please drop me a line. > > Best, > Alejandro.- > > > -- > http://alejandrosegovia.net > > > > > -- > http://alejandrosegovia.net > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Alejandro S. <as...@gm...> - 2011-07-12 02:43:29
|
Hi Mike, > Okay guys, I managed to get the GLE source code. It was found laying in a > SourceForge project. > > http://sourceforge.net/projects/gle/ > > By default it builds as a static library. I ported the project to Visual > C++ 9 (so it links against MSVCRT9.0) and tweaked it to build into a DLL > file. > > I've replaced the old and busted gle32.dll with this new DLL and my > application no longer complains about missing the MSVCRT7.1 runtime. > > Mike, would you agree on replacing the old DLL in the PyOpenGL source > bundle with this one? > > IIRC we need to have multiple versions and choose the correct one based on > which Python we are installing into. I've tagged this as a todo for myself. > Would you like me to send the compiled DLL over? Let me know if I can help. Alejandro.- > On Mon, Jul 4, 2011 at 3:15 PM, Alejandro Segovia <as...@gm...>wrote: > >> Hi Henry, >> >> Thanks for all the help. The CRT versioning discussion was a great read. >> >> >> It seems that the gle32.dll packaged with PyOpenGL has this >>> >> dependency, so its this library that needs to be recompiled. >>> >>> It also seems to be a fairly minimal change to remove the GLE >>> functionality entirely under Windows. Certainly, I won't be needing it. >>> >> >> Yes, I think I'll go this way too. I'll try to find whatever code >> requests this DLL to be loaded and nuke it. I just hope nothing breaks. >> >> It would still be nice being able to recompile this library and patch >> PyOpenGL. I found this other page using Google: >> http://brightideassoftware.com/GLE32Downloads.aspx but the source code is >> incomplete and I can't build it. >> >> If anyone has the GLE32 code, please drop me a line. >> >> Best, >> Alejandro.- >> >> >> -- >> http://alejandrosegovia.net >> >> > > > -- > http://alejandrosegovia.net > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > > > _______________________________________________ > PyOpenGL Homepagehttp://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > -- http://alejandrosegovia.net |
From: Henry G. <he...@ca...> - 2011-07-12 07:45:42
|
On Mon, 2011-07-11 at 23:43 -0300, Alejandro Segovia wrote: > > Would you like me to send the compiled DLL over? I would please. I'm sure it would be useful to others, so I can push it onto my github repository for the time being if you're happy with that. In which case, could you send the source over as well. Were there any changes? Cheers, Henry |
From: Alejandro S. <as...@gm...> - 2011-07-12 13:12:09
|
On Tue, Jul 12, 2011 at 4:45 AM, Henry Gomersall <he...@ca...> wrote: > On Mon, 2011-07-11 at 23:43 -0300, Alejandro Segovia wrote: > > > > Would you like me to send the compiled DLL over? > > I would please. I'm sure it would be useful to others, so I can push it > onto my github repository for the time being if you're happy with that. > In which case, could you send the source over as well. Were there any > changes? > Okay, I have everything ready: the DLL and the source. The only changes I had to make were to convert the GLE source to a Visual C++ 9 project and then change the project configuration to generate a DLL instead of a static link library (.LIB). Should I just attach the files to a mail message or do you have a FTP site? It's a little more than 5MB in size. Alejandro.- -- http://alejandrosegovia.net |
From: Henry G. <he...@ca...> - 2011-07-12 13:20:16
|
On Tue, 2011-07-12 at 10:11 -0300, Alejandro Segovia wrote: > The only changes I had to make were to convert the GLE source to a > Visual C++ 9 project and then change the project configuration to > generate a DLL instead of a static link library (.LIB). > > Should I just attach the files to a mail message or do you have a FTP > site? It's a little more than 5MB in size. Its probably easiest to email it to me personally and I'll send a link to the list. Cheers, Henry |
From: Henry G. <he...@ca...> - 2011-07-12 19:50:59
|
On Tue, 2011-07-12 at 14:20 +0100, Henry Gomersall wrote: > On Tue, 2011-07-12 at 10:11 -0300, Alejandro Segovia wrote: > > The only changes I had to make were to convert the GLE source to a > > Visual C++ 9 project and then change the project configuration to > > generate a DLL instead of a static link library (.LIB). > > > > Should I just attach the files to a mail message or do you have a > FTP > > site? It's a little more than 5MB in size. > > Its probably easiest to email it to me personally and I'll send a link > to the list. There is now a github repository containing the updated gle32.dll file and the source tree used to compile it. This can be found at: https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows I'm not in a position to test it at the moment, but I will do in the next few days. Thanks for that Alejandro. Cheers, Henry |
From: Alejandro S. <as...@gm...> - 2011-07-12 20:02:18
|
> > Thanks for that Alejandro. > No problemo! Let me know how it goes. Best, Alejandro.- PS: Stay tuned for more PyOpenGL/Windows adventures as I stumble across new blocks along the way (like trying to use cx_Freeze with PyOpenGL). Crashing a thread near you soon ;) -- http://alejandrosegovia.net |