pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Failure to build on Linux

[Mike C. F. <mcf...@ro...>]

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/

Re: [PyOpenGL-Users] Failure to build on Linux

[Richard J. <ric...@op...>]

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

Re: [PyOpenGL-Users] win32 installer for python 2.3

[Mike C. F. <mcf...@ro...>]

John Carter mentioned that he'd built a binary for Win32 a few days ago 
from 2.0.1.07, and I'm afraid I somewhat dropped the ball on getting it 
uploaded to SourceForge.  Hopefully he's still willing :) .

Arthur provides a "minimal" build of 2.0.1.04, which is missing most of 
the OpenGL extensions here:

    http://home.ix.netcom.com/~ajs/download/

If someone wants to stand up and declare themselves a packager for 
Win32, please do so.  About the only technical requirement is a fairly 
secure PC with decent anti-virus, Python 2.2/2.3 w/ Numeric and MSVC++ 
6.0.  Requires that you be willing to build new versions, given them a 
quick once-over test, and upload them to SourceForge's incoming 
directory.  To some extent it requires that you be someone people can 
generally trust to run a secure, non-infected machine, and not implant 
anything malicious in the package.

Enjoy yourself,
Mike

Scott Hathaway wrote:

> Does anyone have a binary windows install for pyOpenGL for Python 2.3 
> that can be made available for download?  I do not have a C compiler 
> (or any knowledge of how to compile something if I did).  If not, if 
> someone could point me where to get a C compiler and how to do this, I 
> will make it available for everyone.
>  
> I have a couple of python modules that I want to use (pyUI and pyGame) 
> that need this library.
>  
> Thanks,
> Scott Hathaway

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] Failure to build on Linux

[Richard J. <ric...@op...>]

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

Re: [PyOpenGL-Users] Failure to build on Linux

[Mike C. F. <mcf...@ro...>]

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/

[PyOpenGL-Users] Failure to build on Linux

[Richard J. <ric...@op...>]

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

[PyOpenGL-Users] win32 installer for python 2.3

[Scott H. <sl...@ch...>]

Does anyone have a binary windows install for pyOpenGL for Python 2.3 =
that can be made available for download?  I do not have a C compiler (or =
any knowledge of how to compile something if I did).  If not, if someone =
could point me where to get a C compiler and how to do this, I will make =
it available for everyone.

I have a couple of python modules that I want to use (pyUI and pyGame) =
that need this library.

Thanks,
Scott Hathaway

Re: [PyOpenGL-Users] glDrawRangeElements, GL_MAX_ELEMENTS_VERTICES& GL_MAX_ELEMENTS_INDICES

[Andrew S. <as...@in...>]

> Andrew Straw wrote:
>
>> Check this thread out:
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=6131991
>>
>> (Note the continuations seem to be a month later!)
>>
>> I think we should implement a Python runtime check for OpenGL version
>> number and modify the namespace accordingly.  Too bad I don't have
>> time for the next several months, at least!
>
> Hmm, I think that would require that the system used to build the binary
> have up to 1.3/1.4 available in it's library, wouldn't it?  The wrappers
> are generated for each version of OpenGL present in the platform's
> OpenGL library.  Without those libraries I can't see how to compile the
> wrappers.  I may be missing something, though.

I think you're mainly right, although with dynamic library access using
something like  ctypes, it should be possible using just a header file,
not necessarily the lib. (Although with ctypes, as you pointed out before,
this may be a bit slow.)  I guess this mimcs the present situation of
building on a platform with 1.2 binaries but running on a 1.1 platform.

We really should implement some sort of runtime version check to limit the
namespace, at least, because it's rather confusing to have a bunch of 1.2
symbols available when your system is only 1.1.

Re: [PyOpenGL-Users] glDrawRangeElements, GL_MAX_ELEMENTS_VERTICES & GL_MAX_ELEMENTS_INDICES

[Mike C. F. <mcf...@ro...>]

Andrew Straw wrote:

> Check this thread out:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=6131991
>
> (Note the continuations seem to be a month later!)
>
> I think we should implement a Python runtime check for OpenGL version 
> number and modify the namespace accordingly.  Too bad I don't have 
> time for the next several months, at least!

Hmm, I think that would require that the system used to build the binary 
have up to 1.3/1.4 available in it's library, wouldn't it?  The wrappers 
are generated for each version of OpenGL present in the platform's 
OpenGL library.  Without those libraries I can't see how to compile the 
wrappers.  I may be missing something, though.

Would be nice to get a 1.4 windows DLL to test all these hypothetically 
supported features :) .

Anyway, to the OP, for this particular case, it's quite easy just to use 
the numeric values for the GL_MAX_ELEMENTS_VERTICES constants.  Not a 
solution, but a work-around.

Take care,
Mike

>
> Cheers!
>
> Andrew
>
...

>> I know this functionnality are new in OpenGL1.3, but if this 
>> functionnality
>> is documented, what's the difficulty ?
>>
>>
>> PB
>
...

Re: [PyOpenGL-Users] glDrawRangeElements, GL_MAX_ELEMENTS_VERTICES & GL_MAX_ELEMENTS_INDICES

[Andrew S. <as...@in...>]

Check this thread out:

http://sourceforge.net/mailarchive/message.php?msg_id=6131991

(Note the continuations seem to be a month later!)

I think we should implement a Python runtime check for OpenGL version 
number and modify the namespace accordingly.  Too bad I don't have time 
for the next several months, at least!

Cheers!

Andrew

On Sunday, Dec 14, 2003, at 22:12 Australia/Adelaide, 
<ba...@fr...> wrote:

> hi,
> i wanted to use glDrawRangeElements, so i have to know what are the 
> values
> of glGetIntegerv(GL_MAX_ELEMENTS_VERTICES) and
> glGetIntegerv(GL_MAX_ELEMENTS_INDICES)... but these keywords appear to 
> be
> unknown to my pyOpenGl... a grep in the pyOpenGL directory gives no 
> result
> (although a grep in the GL-includes demonstrates that these keywords 
> are
> presents in my GL.h).
> I know this functionnality are new in OpenGL1.3, but if this 
> functionnality
> is documented, what's the difficulty ?
>
>
> PB
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] glDrawRangeElements, GL_MAX_ELEMENTS_VERTICES & GL_MAX_ELEMENTS_INDICES

[<ba...@fr...>]

hi,
i wanted to use glDrawRangeElements, so i have to know what are the value=
s
of glGetIntegerv(GL_MAX_ELEMENTS_VERTICES) and
glGetIntegerv(GL_MAX_ELEMENTS_INDICES)... but these keywords appear to be
unknown to my pyOpenGl... a grep in the pyOpenGL directory gives no resul=
t
(although a grep in the GL-includes demonstrates that these keywords are
presents in my GL.h).
I know this functionnality are new in OpenGL1.3, but if this functionnali=
ty
is documented, what's the difficulty ?


PB

Re: [PyOpenGL-Users] Re: [PyOpenGL-Devel] rotation problem

[Rene D. <il...@ya...>]

You can do this, and it is a tiny insy bit quicker than push/pop too, 
but may be prone to small float errors if you do it lots.

a = 30.
x,y,z = 1., 0., 0.

# rotate to your place in the gl universe.
glRotatef(a, x,y,z)
something_rotated()
# rotate back
glRotatef(a,-x,-y,-z)

You can get the current matrix with glLoadMatrix(...) but not the 
transformed coordinates.  Well it is possible with shaders, with a bit 
of effort.


Have fun!
http://www.holepit.com/

[PyOpenGL-Users] Re: [PyOpenGL-Devel] rotation problem

[<dri...@ya...>]

hi,
 
thanks a lot for help!
 
i tried using the glPushMatrix() and glPopMatrix() as suggested by the examples, but the coordinate system still seems to rotate. 
 
like when i rotate at initial position along x and y the rotation seems to be proper, but now after doing so if i rotate along z then my z axis seems to have changed ... giving a feeling that the coordiante system has changed?

also is there a way to get the updated coordinates of the rotated object?
 
regards

"Mike C. Fletcher" <mcf...@ro...> wrote:
You'll want to push and pop a matrix stack to do rotation. You can find 
demo code for glPushMatrix linked here:

http://pyopengl.sourceforge.net/documentation/manual/glPushMatrix.3G.xml

BTW, most OpenGL tutorials, such as the red book or NeHe will cover 
matrix-stack manipulations.

HTH,
Mike

Drishti Integra wrote:

> hi,
> 
> i am a newbee to pyopengl.
> would be very kind if any one can guide me for the following:
> 
> i am trying to rotate a few objects using glRotate(). but this seems 
> to rotate the whole coordinates system as well as any lightings i have 
> used. is there a way to rotate only objects and not the coordinate 
> system and lights.
> 
> thanks and regards

_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/



Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now.

[PyOpenGL-Users] Re: [PyOpenGL-Devel] rotation problem

[Mike C. F. <mcf...@ro...>]

You'll want to push and pop a matrix stack to do rotation.  You can find 
demo code for glPushMatrix linked here:

http://pyopengl.sourceforge.net/documentation/manual/glPushMatrix.3G.xml

BTW, most OpenGL tutorials, such as the red book or NeHe will cover 
matrix-stack manipulations.

HTH,
Mike

Drishti Integra wrote:

> hi,
>  
> i am a newbee to pyopengl.
> would be very kind if any one can guide me for the following:
>  
> i am trying to rotate a few objects using glRotate(). but this seems 
> to rotate the whole coordinates system as well as any lightings i have 
> used. is there a way to rotate only objects and not the coordinate 
> system and lights.
>  
> thanks and regards

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Re: GLUT with another toolbox

[Mike C. F. <mcf...@ro...>]

Oops, forgot to attach the module...

Sorry,
Mike

Mike C. Fletcher wrote:

> I've attached a minimal module that shows simple OpenGLContext use 
> with wxPython.  

...

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

[PyOpenGL-Users] Re: GLUT with another toolbox

[Mike C. F. <mcf...@ro...>]

Hi Fulko,

Normally the best place to ask questions about PyOpenGL is the PyOpenGL 
users list here:

    http://sourceforge.net/mail/?group_id=5988

As to your question(s), I'm not sure why you would want to combine GLUT 
(the windowing system built on top of OpenGL) and another windowing 
system such as Tk/GTK/Qt.  It's not necessary to have the GLUT windowing 
system active to use the GLUT utility code (e.g. primitive shape drawing 
or text-drawing), in case that's what's hanging you up.

In general, each windowing toolkit (GLUT/Tk/PyGame/GTK/Qt/wxPython/FxPy) 
offers its own widgets, which normally include an OpenGL "context" 
widget.  It is almost always difficult and error prone (likely to crash) 
to mix widgets and/or windows from the different windowing toolkits, so 
you'd want to choose a windowing toolkit, and then use the widgets that 
toolkit provides.

As a note, Tk support is being dropped from PyOpenGL, so choosing it as 
a platform for new development probably isn't a good choice.  PyGame 
tends to be the easiest to work with for game development, as it's got 
lots of game-oriented functionality (strangely), but very few pre-build 
UI widgets.  wxPython is the toolkit I personally use the most with 
PyOpenGL, and it has a fairly robust and extensive set of widgets.  Qt 
and GTK have OpenGL widgets IIRC, but I've never used them.  FxPy's 
OpenGL widget was functional last time I looked, but it's been a while.

As for demo code, the OpenGLContext project has code for creating 
wxPython, contexts.  The code is just regular wxPython code, with the 
wxPython OpenGL context responding to wxPython events as seen in the 
wxPython OpenGLContext.  I've attached a minimal module that shows 
simple OpenGLContext use with wxPython.  The code just controls the 
timer that rotates a red box.  The raw wxPython OpenGL context works in 
much the same way as the wxinteractivecontext (which is a wxPython 
OpenGL context sub-class), you can find the demo in the wxPython demo 
for use of the raw widget.

HTH,
Mike

Fulko van Westrenen wrote:

>Hello,
>
>A few days ago I asked help with GLUT/Tk. This combination seems to be 
>difficult. Is there another combination with GLUT, like GTK or Qt, or a
>true GLUT widget-set that I can use to make buttons,sliders,dials,etc?
>
>If there is such a combination, does it come with example code (I learn
>through examples)?
>
>Thanks,
>Fulko
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] python2.3 - win2k - problems compiling

[Mike C. F. <mcf...@ro...>]

Marcelo de Freitas Rigon wrote:

>Thanks for your help Mike... 
>
>I really had  forgot to include de lib directory in the MSVC. After making 
>what you told me to do, i had not to face this error anymore. However, now, 
>there is a new error and if it's a file that is missing I couldn't figure 
>out which. 
>
>GL.GL__init___.obj : error LNK2001: unresolved external symbol 
>initGL__init___ 
>  
>
This is part of PyOpenGL itself, it's the primary (only) entry point in 
the OpenGL.GL implementation pyd (GL__init___.pyd).  Not sure how it 
could be left out of the library, as it definitely shows up in the 
2.0.1.04 build on my system.  Might be that you've possibly got an old 
version compiled with something wonky that renamed the initGL__init__ 
method with different decoration.  Other possibility is that *I've* got 
something wonky providing it, but I don't think so, as I regularly blow 
away my build directory to force a clean rebuild.  You might try a 
setup.py build_ext --clean before doing another setup.py build_ext (or 
just kill the build directory and re-try).

BTW, you are using at least SP3 of Visual Studio?  Not sure if it 
matters, but I'd recommend SP5 unless you have some reason not to update 
your Visual Studio.  Can't think of anything else at the moment (I'm 
working on day-job stuff today, so no time to play), so if anyone else 
on PyOpenGL users has a suggestion, pipe up :) .

Good luck again,
Mike

 
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [PyOpenGL-Users] python2.3 - win2k - problems compiling

[Marcelo de F. R. <are...@ig...>]

Thanks for your help Mike... 

I really had  forgot to include de lib directory in the MSVC. After making 
what you told me to do, i had not to face this error anymore. However, now, 
there is a new error and if it's a file that is missing I couldn't figure 
out which. 

GL.GL__init___.obj : error LNK2001: unresolved external symbol 
initGL__init___ 
build\temp.win32-2.3\Release\src/interface\GL__init___.lib : fatal error 
LNK1120: 1 unresolved externals 
LINK : fatal error LNK1141: failure during build of exports file 
error: command '"C:\Arquivos de programas\Microsoft Visual 
Studio\VC98\BIN\link.exe"' failed with exit status 1141 

In my lib directory there is every lib I could get from the site you sent 
and it's links that was related to openGL, Glu or GLUT. 

Thanks for your support again, 
Marcelo de Freitas Rigon 

Em 08 Nov 2003, Mike C. Fletcher escreveu: 

>Okay, mingw32 and cygwin are both known to fail on building. I haven't 
>got time to track down why. Anyone who wants to build and send in a 
>patch set would be most welcome to try. 
> 
>MSVC 6.0 is my primary development environment, so it's definitely able 
>to build, so let's concentrate on that. First, kill off any "source 
>directory/build" directory so you know you're starting fresh. Then make 
>sure that you have GLUT compiled and the GLUT .h and .lib files in your 
>include and library paths respectively. Then make sure your OpenGL and 
>GLU headers and libs are similarly in the include/library paths. You 
>can find instructions for this here: 
> 
>http://pyopengl.sourceforge.net/documentation/installation.html 
> 
>in the section "Building PyOpenGL". 
> 
>To me, it looks as though you've got the GLUT headers available, but not 
>the GLUT .lib files. 
> 
>Only once you have those dependencies in the right places can PyOpenGL 
>build. 
> 
>Good luck, 
>Mike 
> 
>Marcelo de Freitas Rigon wrote: 
> 
>>Sorry if you have already answered this to another one, but I couldn't 
find 
>>anything on the list yet. 
>> 
>>when I'm executing "python setup.py install" in mingw using msvc6, the 
>>following error appear: 
>> 
>> 
>... 
> 
>>GLUT.obj : error LNK2001: unresolved external symbol 
>>__imp____glutInitWithExit@12 
>> 
>> 
>... 
> 
>>I tried with mingw32, cygwin and none of then works (but the others I 
>>couldn't understand the error also). 
>> 
>>Thanks, 
>>Marcelo de Freitas Rigon 
>> 
>>_________________________________________________________ 
>>Voce quer um iGMail protegido contra vírus e spams? 
>>Clique aqui: http://www.igmailseguro.ig.com.br 
>>Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/ 
>> 
>> 
>> 
>>------------------------------------------------------- 
>>This SF.Net email sponsored by: ApacheCon 2003, 
>>16-19 November in Las Vegas. Learn firsthand the latest 
>>developments in Apache, PHP, Perl, XML, Java, MySQL, 
>>WebDAV, and more! http://www.apachecon.com/ 
>>_______________________________________________ 
>>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://members.rogers.com/mcfletch/ 
> 
>------------------------------------------------------- 
>This SF.Net email sponsored by: ApacheCon 2003, 
>16-19 November in Las Vegas. Learn firsthand the latest 
>developments in Apache, PHP, Perl, XML, Java, MySQL, 
>WebDAV, and more! http://www.apachecon.com/ 
>_______________________________________________ 
>PyOpenGL Homepage 
>http://pyopengl.sourceforge.net 
>_______________________________________________ 
>PyOpenGL-Users mailing list 
>PyO...@li... 
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users 
> 
>---------- 


--------------------------------------------------------------------------- 
                                  Marcelo de Freitas Rigon 
                       (Mondain Wiz, chaos and darkness is his blood) 

"Unto he whom seeks divination and the understanding of his lord, seek thee 
the unbridled power that exists within Sosaria's core. Let nothing stand 
between thine ways and let nothing obscure the vision of thy goal. Within 
these, one shall summon the strength to force the wretched upon their 
knees..." (The Book of Mondain - Screaming IX:3) 

_________________________________________________________
Voce quer um iGMail protegido contra vírus e spams?
Clique aqui: http://www.igmailseguro.ig.com.br
Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/

Re: [PyOpenGL-Users] python2.3 - win2k - problems compiling

[Mike C. F. <mcf...@ro...>]

Okay, mingw32 and cygwin are both known to fail on building.  I haven't 
got time to track down why.  Anyone who wants to build and send in a 
patch set would be most welcome to try.

MSVC 6.0 is my primary development environment, so it's definitely able 
to build, so let's concentrate on that.  First, kill off any "source 
directory/build" directory so you know you're starting fresh.  Then make 
sure that you have GLUT compiled and the GLUT .h and .lib files in your 
include and library paths respectively.  Then make sure your OpenGL and 
GLU headers and libs are similarly in the include/library paths.  You 
can find instructions for this here:

http://pyopengl.sourceforge.net/documentation/installation.html

in the section "Building PyOpenGL".

To me, it looks as though you've got the GLUT headers available, but not 
the GLUT .lib files.

Only once you have those dependencies in the right places can PyOpenGL 
build.

Good luck,
Mike


Marcelo de Freitas Rigon wrote:

>Sorry if you have already answered this to another one, but I couldn't find 
>anything on the list yet. 
>
>when I'm executing "python setup.py install" in mingw using msvc6, the 
>following error appear: 
>  
>
...

>GLUT.obj : error LNK2001: unresolved external symbol 
>__imp____glutInitWithExit@12 
>  
>
...

>I tried with mingw32, cygwin and none of then works (but the others I 
>couldn't understand the error also). 
>
>Thanks, 
>Marcelo de Freitas Rigon 
>
>_________________________________________________________
>Voce quer um iGMail protegido contra vírus e spams? 
>Clique aqui: http://www.igmailseguro.ig.com.br
>Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: ApacheCon 2003,
>16-19 November in Las Vegas. Learn firsthand the latest
>developments in Apache, PHP, Perl, XML, Java, MySQL,
>WebDAV, and more! http://www.apachecon.com/
>_______________________________________________
>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://members.rogers.com/mcfletch/

[PyOpenGL-Users] python2.3 - win2k - problems compiling

[Marcelo de F. R. <are...@ig...>]

Sorry if you have already answered this to another one, but I couldn't find 
anything on the list yet. 

when I'm executing "python setup.py install" in mingw using msvc6, the 
following error appear: 

C:\Arquivos de programas\Microsoft Visual Studio\VC98\BIN\link.exe /DLL 
/nologo /INCREMENTAL:NO /LIBPATH:../lib /LIBPATH:d:\progs\Python\libs 
/LIBPATH:d:\progs\Python\PCBuild /LIBPATH:build\temp.win32-2.3 opengl32.lib 
glu32.lib glut32.lib interface_util.lib /EXPORT:initGLUT 
build\temp.win32-2.3\Release\src/interface/GLUT.obj 
/OUT:build\lib.win32-2.3\OpenGL\GLUT.pyd 
/IMPLIB:build\temp.win32-2.3\Release\src/interface\GLUT.lib 
   Creating library build\temp.win32-2.3\Release\src/interface\GLUT.lib and 
object build\temp.win32-2.3\Release\src/interface\GLUT.exp 
GLUT.obj : error LNK2001: unresolved external symbol 
__imp____glutInitWithExit@12 
GLUT.obj : error LNK2001: unresolved external symbol 
__imp____glutCreateMenuWithExit@8 
GLUT.obj : error LNK2001: unresolved external symbol 
__imp____glutCreateWindowWithExit@8 
build\lib.win32-2.3\OpenGL\GLUT.pyd : fatal error LNK1120: 3 unresolved 
externals 
error: command '"C:\Arquivos de programas\Microsoft Visual 
Studio\VC98\BIN\link.exe"' failed with exit status 1120 

I tried with mingw32, cygwin and none of then works (but the others I 
couldn't understand the error also). 

Thanks, 
Marcelo de Freitas Rigon 

_________________________________________________________
Voce quer um iGMail protegido contra vírus e spams? 
Clique aqui: http://www.igmailseguro.ig.com.br
Ofertas imperdíveis! Link: http://www.americanas.com.br/ig/

Re: [PyOpenGL-Users] pyopengl nvidia and libc.

[Rene D. <il...@ya...>]

Hey,

glxgears would run.  However that doesn't use dlopen.  It is linked with 
pthread if that makes a difference.  Which is why I think it is related 
to the libc thing mentioned in the nvidia faq. 

I checked with ldd to see if pthread was linked with the pyopengl  .soS  
and it wasn't.  Which is probably a bug in pyopengl, as it is not 
respecting the python2.3 makefiles LIBS.  However it does respect the CC 
in the python2.3 makefile(which happens to be gcc -pthread).  I tried 
linking with pthread, and without pthread, with still the same error.

Both GLcore, and dri were commented out.

What I was thinking is to somehow tell pyopengl to use dlopen on a 
specific gl driver.  For example like quake2/hexen2 used to do with a 
symlink to mesa.  But I am sure the tls libraries are there for a 
reason, just that the system seems kind of kludgey.  Too many damn 
thread implementations on linux ;)

Perhaps something like this:

try:
    import GL__init___normal
except:
    try:
        import GL__init___nottls
    except:
        import GL__init___mesa

Where it tries the normal linker determined version, then tries to load 
non tls directly ie /usr/lib/libGL.so.  If that fails try and load mesa.

This could be useful for having mesa sticking around somewhere as a 
backup on windows too.  If they do not have an opengl capable system.





Joe Connellan wrote:

> Hi Rene, can you run other openGL apps?
>
> you may have done this already but make sure you've commented out the 
> following lines in your /etc/X11/XF86Config file when using nvidias 
> XFree86 drivers
> Load  "GLcore"
> Load "dri"
>
> they are in the "Module" section
>
> I'm not positive this will fix your problem but GLcore.so lives in 
> /usr/lib/tls and since it appears deleting this file may have fixed 
> your problem it could be related, though without doing this in the 
> XFree86Config file the problem may arise again when installing new 
> drivers, or possibly break something if you change video cards or want 
> to go back to the standard nvidia ("nv") xfree drivers.
>
> hope that helps,
>
> Joe
>
>> From: Rene Dudfield <il...@ya...>
>> To: pyo...@li...
>> Subject: Re: [PyOpenGL-Users] pyopengl nvidia and libc.
>> Date: Thu, 06 Nov 2003 13:56:19 +1000
>>
>> After much playing around, it seems something which works is to rm 
>> -rf /usr/lib/tls/libGL*
>>
>> Not sure who report the bug to.  I guess nvidia.  However they 
>> haven't responded in the past, so hopefully it'll just get fixed.
>>
>>
>>
>> Rene Dudfield wrote:
>>
>>> Hello,
>>>
>>> anyone had the misfortune of comming accross a problem using 
>>> pyopengl with nvidia drivers on linux?  I think it has something to 
>>> do with a recent libc.
>>>
>>> The error I get is:
>>>  File "/usr/lib/python2.3/site-packages/OpenGL/GL/GL__init__.py", 
>>> line 2, in ?
>>>    import GL__init___
>>> ImportError: libGL.so.1: cannot handle TLS data
>>>
>>> Anyone know a fix?
>>>
>>>
>>> From nvidias FAQ:
>>>
>>> Q: Some OpenGL applications (like Quake3 Arena) crash when I start them
>>>   on Red Hat Linux 9.0.
>>>
>>> A: Some versions of the glibc package shipped by Red Hat that support
>>>   TLS do not properly handle using dlopen() to access shared libraries
>>>   which utilize some TLS models.  This problem is exhibited, for 
>>> example,
>>>   when Quake3 Area dlopen()'s NVIDIA's libGL library.  Please obtain
>>>   at least glibc-2.3.2-11.9 which is available as an update from Red 
>>> Hat.
>>>
>>> I think on debian unstable it is version: 2.3.2.ds1-9.  I have no 
>>> idea if this is like the fixed redhat glibc.  I guess it will 
>>> probably be fixed in a newer version.  If this is the problem...
>>>
>>> arg, this whole TLS/threads thing is a mess.  Probably should stay 
>>> away from upgrading debian unstable for a little while if you want 
>>> to use pyopengl.
>>>
>>> I have tried enabling, and disabling pthread in the linking and 
>>> compiling stages of pyopengl, with no luck.
>>>
>>>
>>
>>
>>

Re: [PyOpenGL-Users] pyopengl nvidia and libc.

[Joe C. <joe...@ho...>]

Hi Rene, can you run other openGL apps?

you may have done this already but make sure you've commented out the 
following lines in your /etc/X11/XF86Config file when using nvidias XFree86 
drivers
Load  "GLcore"
Load "dri"

they are in the "Module" section

I'm not positive this will fix your problem but GLcore.so lives in 
/usr/lib/tls and since it appears deleting this file may have fixed your 
problem it could be related, though without doing this in the XFree86Config 
file the problem may arise again when installing new drivers, or possibly 
break something if you change video cards or want to go back to the standard 
nvidia ("nv") xfree drivers.

hope that helps,

Joe

>From: Rene Dudfield <il...@ya...>
>To: pyo...@li...
>Subject: Re: [PyOpenGL-Users] pyopengl nvidia and libc.
>Date: Thu, 06 Nov 2003 13:56:19 +1000
>
>After much playing around, it seems something which works is to rm -rf 
>/usr/lib/tls/libGL*
>
>Not sure who report the bug to.  I guess nvidia.  However they haven't 
>responded in the past, so hopefully it'll just get fixed.
>
>
>
>Rene Dudfield wrote:
>
>>Hello,
>>
>>anyone had the misfortune of comming accross a problem using pyopengl with 
>>nvidia drivers on linux?  I think it has something to do with a recent 
>>libc.
>>
>>The error I get is:
>>  File "/usr/lib/python2.3/site-packages/OpenGL/GL/GL__init__.py", line 2, 
>>in ?
>>    import GL__init___
>>ImportError: libGL.so.1: cannot handle TLS data
>>
>>Anyone know a fix?
>>
>>
>>From nvidias FAQ:
>>
>>Q: Some OpenGL applications (like Quake3 Arena) crash when I start them
>>   on Red Hat Linux 9.0.
>>
>>A: Some versions of the glibc package shipped by Red Hat that support
>>   TLS do not properly handle using dlopen() to access shared libraries
>>   which utilize some TLS models.  This problem is exhibited, for example,
>>   when Quake3 Area dlopen()'s NVIDIA's libGL library.  Please obtain
>>   at least glibc-2.3.2-11.9 which is available as an update from Red Hat.
>>
>>I think on debian unstable it is version: 2.3.2.ds1-9.  I have no idea if 
>>this is like the fixed redhat glibc.  I guess it will probably be fixed in 
>>a newer version.  If this is the problem...
>>
>>arg, this whole TLS/threads thing is a mess.  Probably should stay away 
>>from upgrading debian unstable for a little while if you want to use 
>>pyopengl.
>>
>>I have tried enabling, and disabling pthread in the linking and compiling 
>>stages of pyopengl, with no luck.
>>
>>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?   SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>PyOpenGL Homepage
>http://pyopengl.sourceforge.net
>_______________________________________________
>PyOpenGL-Users mailing list
>PyO...@li...
>https://lists.sourceforge.net/lists/listinfo/pyopengl-users

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp

Re: [PyOpenGL-Users] pyopengl nvidia and libc.

[Rene D. <il...@ya...>]

After much playing around, it seems something which works is to rm -rf 
/usr/lib/tls/libGL*

Not sure who report the bug to.  I guess nvidia.  However they haven't 
responded in the past, so hopefully it'll just get fixed.



Rene Dudfield wrote:

> Hello,
>
> anyone had the misfortune of comming accross a problem using pyopengl 
> with nvidia drivers on linux?  I think it has something to do with a 
> recent libc.
>
> The error I get is:
>  File "/usr/lib/python2.3/site-packages/OpenGL/GL/GL__init__.py", line 
> 2, in ?
>    import GL__init___
> ImportError: libGL.so.1: cannot handle TLS data
>
> Anyone know a fix?
>
>
> From nvidias FAQ:
>
> Q: Some OpenGL applications (like Quake3 Arena) crash when I start them
>   on Red Hat Linux 9.0.
>
> A: Some versions of the glibc package shipped by Red Hat that support
>   TLS do not properly handle using dlopen() to access shared libraries
>   which utilize some TLS models.  This problem is exhibited, for example,
>   when Quake3 Area dlopen()'s NVIDIA's libGL library.  Please obtain
>   at least glibc-2.3.2-11.9 which is available as an update from Red Hat.
>
> I think on debian unstable it is version: 2.3.2.ds1-9.  I have no idea 
> if this is like the fixed redhat glibc.  I guess it will probably be 
> fixed in a newer version.  If this is the problem...
>
> arg, this whole TLS/threads thing is a mess.  Probably should stay 
> away from upgrading debian unstable for a little while if you want to 
> use pyopengl.
>
> I have tried enabling, and disabling pthread in the linking and 
> compiling stages of pyopengl, with no luck.
>
>

[PyOpenGL-Users] pyopengl nvidia and libc.

[Rene D. <il...@ya...>]

Hello,

anyone had the misfortune of comming accross a problem using pyopengl 
with nvidia drivers on linux?  I think it has something to do with a 
recent libc.

The error I get is:
  File "/usr/lib/python2.3/site-packages/OpenGL/GL/GL__init__.py", line 
2, in ?
    import GL__init___
ImportError: libGL.so.1: cannot handle TLS data

Anyone know a fix?


 From nvidias FAQ:

Q: Some OpenGL applications (like Quake3 Arena) crash when I start them
   on Red Hat Linux 9.0.

A: Some versions of the glibc package shipped by Red Hat that support
   TLS do not properly handle using dlopen() to access shared libraries
   which utilize some TLS models.  This problem is exhibited, for example,
   when Quake3 Area dlopen()'s NVIDIA's libGL library.  Please obtain
   at least glibc-2.3.2-11.9 which is available as an update from Red Hat.

I think on debian unstable it is version: 2.3.2.ds1-9.  I have no idea if this is like the fixed redhat glibc.  
I guess it will probably be fixed in a newer version.  If this is the problem...

arg, this whole TLS/threads thing is a mess.  Probably should stay away from upgrading debian unstable for a little while if you want to use pyopengl.

I have tried enabling, and disabling pthread in the linking and compiling stages of pyopengl, with no luck.

Re: [PyOpenGL-Users] Problem during install: can't find package Tk 8.1

[Rene D. <il...@ya...>]

Leonardo wrote:

>Hi, I am trying to install with
>
>python setup.py install
>
>and I got the following error:
>
>copying build/Togl-1.6-tk8.3/Togl.so ->
>/usr/lib/python2.2/site-packages/OpenGL/Tk/linux2-tk8.3
>running "pkg_mkIndex
>/usr/lib/python2.2/site-packages/OpenGL/Tk/linux2-tk8.3
>Togl.so"
>warning: error while loading Togl.so: can't find
>package Tk 8.1
>
>My system:
>
>Red Hat 9.0 with python 2.2 and I already install
>glut-devel-3.7-12.i386.rpm nvidia drivers and Numeric
>23 and gl development (glut-devel-3.7-12.i386.rpm)
>
>I also have Tk 8.3 installed. Should I install 8.1???
>
>#rpm -qai tk
>Name        : tk                          
>Relocations: (not relocateable)
>Version     : 8.3.5                            
>Vendor: Red Hat, Inc.
>Release     : 88                            Build
>Date: Thu 06 Feb 2003 08:41:20 AM CST
>Install Date: Thu 23 Oct 2003 08:32:23 PM CDT     
>Build Host: daffy.perf.redhat.com
>Group       : Development/Languages         Source
>RPM: tcltk-8.3.5-88.src.rpm
>
>
>Help please !!! 
>
>Thanks a lot!
>
>Leonardo
>
>  
>
Hey,

I think there are reports of togl being broken?  If so your choices are 
to disable it, or to fix it.

Disabling it is easier,
in config/[<<yourplatform>>].cfg set
build_togl=0

So for redhat that is config/linux.cfg

Anyone use the togl stuff in something they care about, and want it fixed?

If not I think we should disable building it if it is indeed broken.


Have fun!
http://www.holepit.com/