Thread: [PyOpenGL-Users] Failure to build on Linux
Brought to you by:
mcfletch
From: Richard J. <ric...@op...> - 2003-12-16 02:35:57
|
I just tried to build 2.0.1.07 on Linux (Mandrake 9.1) against python 2.3.2= =2E=20 Used the standard "python setup.py install". It appeared to build OK, but a= ny=20 attempt to use it breaks: [richard@richardpc PyOpenGL-2.0.1.07]$ python Python 2.3.2 (#1, Oct 8 2003, 09:16:48) [GCC 3.3.1 (Mandrake Linux 9.2 3.3.1-0.7mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from OpenGL.GL import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.3/site-packages/OpenGL/__init__.py", line 26, in ? from GL.GL__init___ import __numeric_present__, __numeric_support__ File "/usr/lib/python2.3/site-packages/OpenGL/GL/__init__.py", line 2, in= ? from GL__init__ import * File "/usr/lib/python2.3/site-packages/OpenGL/GL/GL__init__.py", line 4, = in=20 ? import _GL__init__ ImportError: No module named _GL__init__ >>>=20 The contents of OpenGL/GL/ are: _3DFX/ EXT/ IBM/ INTEL/ PGI/ SGIX/ APPLE/ GL__init__.py INGR/ KTX/ REND/ SUN/ ARB/ GL__init__.pyc __init__.py MESA/ S3/ SUNX/ ATI/ GL__init___.so* __init__.pyc NV/ SGI/ WIN/ Autodesk/ HP/ __init___.so* OML/ SGIS/ I renamed the GL__init___.so and __init___.so files to _GL__init__.so and=20 ___init__.so respectively. I also edited OpenGL/__init__.py and=20 OpenGL/GL/__init__.py since they referred to the GL__init___ module. The=20 import of OpenGL.GL works now. Other imports break though ("from OpenGL.GLU= T=20 import *" for example) Richard |
From: Mike C. F. <mcf...@ro...> - 2003-12-16 04:37:39
|
Richard Jones wrote: >I just tried to build 2.0.1.07 on Linux (Mandrake 9.1) against python 2.3.2. >Used the standard "python setup.py install". It appeared to build OK, but any >attempt to use it breaks: > > ... >The contents of OpenGL/GL/ are: > >_3DFX/ EXT/ IBM/ INTEL/ PGI/ SGIX/ >APPLE/ GL__init__.py INGR/ KTX/ REND/ SUN/ >ARB/ GL__init__.pyc __init__.py MESA/ S3/ SUNX/ >ATI/ GL__init___.so* __init__.pyc NV/ SGI/ WIN/ >Autodesk/ HP/ __init___.so* OML/ SGIS/ > > Where are those __init___.so files coming from I wonder? Possibly an old 2.0.0 installation? 2.0.1 should not have any __init___.so files, as they were renamed to GL__init___.so, GLU__init___.so and GLUT__init___.so . I'd suggest nuking your sourcedirectory/build and installationdirectory/OpenGL directories and then re-building/re-installing. >I renamed the GL__init___.so and __init___.so files to _GL__init__.so and >___init__.so respectively. I also edited OpenGL/__init__.py and >OpenGL/GL/__init__.py since they referred to the GL__init___ module. The >import of OpenGL.GL works now. Other imports break though ("from OpenGL.GLUT >import *" for example) > > Um, well, you'd have to do the same for GLU and GLUT as you did for GL. That's *not* recommended, as the new module naming is required to make certain packaging systems work properly, and will not be reversed any time soon. Good luck, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Richard J. <ric...@op...> - 2003-12-16 04:54:42
|
On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote: > Richard Jones wrote: > >The contents of OpenGL/GL/ are: > > > >_3DFX/ EXT/ IBM/ INTEL/ PGI/ SGIX/ > >APPLE/ GL__init__.py INGR/ KTX/ REND/ SUN/ > >ARB/ GL__init__.pyc __init__.py MESA/ S3/ SUNX/ > >ATI/ GL__init___.so* __init__.pyc NV/ SGI/ WIN/ > >Autodesk/ HP/ __init___.so* OML/ SGIS/ > > Where are those __init___.so files coming from I wonder? Possibly an > old 2.0.0 installation? 2.0.1 should not have any __init___.so files, > as they were renamed to GL__init___.so, GLU__init___.so and > GLUT__init___.so . I'd suggest nuking your sourcedirectory/build and > installationdirectory/OpenGL directories and then > re-building/re-installing. Yep, I had an old build in the site-packages dir. So I just noticed,=20 re-running the build again, that a warning flashes past in the console: """ swig -version SWIG Version 1.3.19 Copyright (c) 1995-1998 University of Utah and the Regents of the University of California Copyright (c) 1998-2002 University of Chicago Compiled with i586-mandrake-linux-gnu-g++ Please see http://www.swig.org for reporting bugs and further information WARNING!!! wrong swig version. Need 1.3.13, continuing anyway. swig1.3 -version unable to execute swig1.3: No such file or directory """ Any suggestions, apart from downgrading SWIG? :) Richard |
From: Richard J. <ric...@op...> - 2003-12-16 04:58:13
|
On Tue, 16 Dec 2003 03:54 pm, Richard Jones wrote: > So I just noticed, > re-running the build again, that a warning flashes past in the console: > > """ > swig -version > > SWIG Version 1.3.19 > Copyright (c) 1995-1998 > University of Utah and the Regents of the University of California > Copyright (c) 1998-2002 > University of Chicago > Compiled with i586-mandrake-linux-gnu-g++ > > Please see http://www.swig.org for reporting bugs and further information > WARNING!!! wrong swig version. Need 1.3.13, continuing anyway. > swig1.3 -version > unable to execute swig1.3: No such file or directory > """ > > Any suggestions, apart from downgrading SWIG? :) Oh, just to make it clear: I still get that import error :) Richard |
From: Mike C. F. <mcf...@ro...> - 2003-12-16 05:01:36
|
Richard Jones wrote: ... >Yep, I had an old build in the site-packages dir. So I just noticed, >re-running the build again, that a warning flashes past in the console: > > ... >WARNING!!! wrong swig version. Need 1.3.13, continuing anyway. >swig1.3 -version >unable to execute swig1.3: No such file or directory > > ... >Any suggestions, apart from downgrading SWIG? :) > > Yup, just ignore it. The source distributions come with pre-built wrappers. The warning is just telling you that to build the wrappers from their .i sources requires swig 1.3.13, so it's not going to re-build the wrappers. So, unless you're doing a CVS build, or trying to change a wrapper locally, it's a harmless warning. There should have been a message somewhere saying "using pre-built wrappers" in the same general vicinity as the quoted message, if not, please submit it as a bug report on the SF project so I can take a look next time I'm working on Linux builds. HTH, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Richard J. <ric...@op...> - 2003-12-16 05:14:57
|
On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote: > Richard Jones wrote: > >I just tried to build 2.0.1.07 on Linux (Mandrake 9.1) against python > > 2.3.2. Used the standard "python setup.py install". It appeared to build > > OK, but any attempt to use it breaks: > > ... > > >The contents of OpenGL/GL/ are: > > > >_3DFX/ EXT/ IBM/ INTEL/ PGI/ SGIX/ > >APPLE/ GL__init__.py INGR/ KTX/ REND/ SUN/ > >ARB/ GL__init__.pyc __init__.py MESA/ S3/ SUNX/ > >ATI/ GL__init___.so* __init__.pyc NV/ SGI/ WIN/ > >Autodesk/ HP/ __init___.so* OML/ SGIS/ > > Where are those __init___.so files coming from I wonder? Possibly an > old 2.0.0 installation? 2.0.1 should not have any __init___.so files, > as they were renamed to GL__init___.so, GLU__init___.so and > GLUT__init___.so . OK, the dir now looks like: _3DFX/ Autodesk/ GL__init___.so* __init__.py MESA/ REND/ SGIX/ APPLE/ EXT/ HP/ __init__.pyc NV/ S3/ SUN/ ARB/ GL__init__.py IBM/ INTEL/ OML/ SGI/ SUNX/ ATI/ GL__init__.pyc INGR/ KTX/ PGI/ SGIS/ WIN/ GL__init__.py is definitely still referring to _GL__init__ and not=20 GL__init___. There's references to the former in: =2E/src/interface/GL.GL__init___.0100.inc =2E/src/interface/GL.GL__init___.0101.inc =2E/src/shadow/GL.GL__init__.0100.py =2E/src/shadow/GL.GL__init__.0101.py (and nowhere else) if that helps any. They're obviously constructed as part= of=20 the build process, as they don't exist in the source dist. There's no match= =20 on _GL__init__ in the raw source. I get a ton of these warnings when I run "python setup.py install" on a=20 freshly unpacked source:: interface/complex_typemaps.inc:193: Warning(119): %typemap(ignore) has been= =20 replaced by %typemap(in,numinputs=3D0). interface/complex_typemaps.inc:194: Warning(119): %typemap(ignore) has been= =20 replaced by %typemap(in,numinputs=3D0). and once the build is done, those "interface" and "shadow" files appear. I= =20 blame SWIG 1.3.19 ;) Richard |
From: Mike C. F. <mcf...@ro...> - 2003-12-16 06:29:47
|
Richard Jones wrote: >On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote: > > ... >I get a ton of these warnings when I run "python setup.py install" on a >freshly unpacked source:: > >interface/complex_typemaps.inc:193: Warning(119): %typemap(ignore) has been >replaced by %typemap(in,numinputs=0). >interface/complex_typemaps.inc:194: Warning(119): %typemap(ignore) has been >replaced by %typemap(in,numinputs=0). > >and once the build is done, those "interface" and "shadow" files appear. I >blame SWIG 1.3.19 ;) > > Me too :) :-/ , the .inc files are SWIG inputs, they shouldn't be used if you're using the pre-built wrappers. Try doing a clean unpack and then running python setup.py build_ext install, which should skip the build_w (wrapper) stage. Alternately, change the binary search path to *not* point to swig 1.3.19 while building. Entering a bug report about SWIG 1.3.19 confusing the SWIG-checking code would be a help as well, though I'll leave this message marked as todo so I should remember to do it at some point. HTH, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Richard J. <ric...@op...> - 2003-12-16 08:15:41
|
On Tue, 16 Dec 2003 05:29 pm, Mike C. Fletcher wrote: > Richard Jones wrote: > >On Tue, 16 Dec 2003 03:37 pm, Mike C. Fletcher wrote: > > ... > > >I get a ton of these warnings when I run "python setup.py install" on a > >freshly unpacked source:: > > > >interface/complex_typemaps.inc:193: Warning(119): %typemap(ignore) has > > been replaced by %typemap(in,numinputs=3D0). > >interface/complex_typemaps.inc:194: Warning(119): %typemap(ignore) has > > been replaced by %typemap(in,numinputs=3D0). > > > >and once the build is done, those "interface" and "shadow" files appear.= I > >blame SWIG 1.3.19 ;) > > Me too :) :-/ , the .inc files are SWIG inputs, they shouldn't be used > if you're using the pre-built wrappers. Try doing a clean unpack and > then running python setup.py build_ext install, which should skip the > build_w (wrapper) stage. This doesn't work. I get an error regarding a missing library=20 "interface_util". > Alternately, change the binary search path to=20 > *not* point to swig 1.3.19 while building. Tried this, still no dice :( Will look into it some more tomorrow. Richard |
From: Rene D. <re...@py...> - 2003-12-17 15:34:18
|
Hi, downgrade to swig 1.3.13 if you want it to work. Or install 1.3.13 somewhere not in your main path, and have your pyopengl build have it in its path before the normal swig path. I just started working on making pyopengl work with 1.3.19. However I'm having trouble with the GLU wrapper segfaulting, so it may take a while to debug. Anyone allready got pyopengl working with 1.3.19? Have fun! |
From: Richard J. <ric...@op...> - 2004-01-21 23:07:10
|
On Thursday 18 December 2003 02:34, Rene Dudfield wrote: > downgrade to swig 1.3.13 if you want it to work. Or install 1.3.13 > somewhere not in your main path, and have your pyopengl build have it in > its path before the normal swig path. > > I just started working on making pyopengl work with 1.3.19. However I'm > having trouble with the GLU wrapper segfaulting, so it may take a while > to debug. > > Anyone allready got pyopengl working with 1.3.19? Any chance this is remedied yet? Richard |
From: Rene D. <re...@py...> - 2004-01-22 00:14:06
|
Richard Jones wrote: >On Thursday 18 December 2003 02:34, Rene Dudfield wrote: > > >>downgrade to swig 1.3.13 if you want it to work. Or install 1.3.13 >>somewhere not in your main path, and have your pyopengl build have it in >>its path before the normal swig path. >> >>I just started working on making pyopengl work with 1.3.19. However I'm >>having trouble with the GLU wrapper segfaulting, so it may take a while >>to debug. >> >>Anyone allready got pyopengl working with 1.3.19? >> >> > >Any chance this is remedied yet? > > > Richard > > Nope, no luck :( I've kind of given up on working with the new swig for the moment to try ctypes. Mainly because swig was giving me grief! Your best chance may be to use the pregenerated wrapper files, or download swig 1.3.13. |