This has been fixed for a long time in the 2.0.1 branch. Here's the
current linux.cfg file for the include and lib paths:
include_dirs=/usr/include:/usr/local/include:/usr/X11/include:/usr/X11R6/include
library_dirs=/usr/lib:/usr/local/lib:/usr/X11/lib:/usr/X11R6/lib
Enjoy,
Mike
Martin Schaffner wrote:
> Hi,
>
> When I tried to build PyOpenGL on my ibook (Yellow Dog Linux 3.0), it
> wouldn't find the X installation. I applied the following patch and it
> worked. Maybe the same thing needs to be done for other platforms,
> since the File Hierarchy Standard states that the files of the X
> installation should be in /usr/X11R6, and not in /usr/X11.
>
>
>
> Martin
--
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Hi,
When I tried to build PyOpenGL on my ibook (Yellow Dog Linux 3.0), it
wouldn't find the X installation. I applied the following patch and it
worked. Maybe the same thing needs to be done for other platforms,
since the File Hierarchy Standard states that the files of the X
installation should be in /usr/X11R6, and not in /usr/X11.

I'm trying to understand what/how/if PyOpenGL deals with multiple
versions of OpenGL. For example, if I run PyOpenGL on a machine with
OpenGL 1.3 libraries, I should have multitexturing abilities built-in
(e.g. glActiveTexture() function). This is specified in the OpenGL 1.3
spec:
http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf
Another example is that with OpenGL 1.2, the GL_CLAMP_TO_EDGE constant
should be defined.
However, PyOpenGL doesn't provide these names in the GL module when run
on an appropriate system. I wonder if this is simply an oversight
which would be easily fixed, a purposeful omission because runtime GL
version checking and name exporting may be tricky, or has never been
thought about.
Incidentally, on linux, I can get around the missing glActiveTexture()
function by using ctypes to load the function. (On Windows, I get an
error that the arguments must be 4 bytes longer... I haven't tracked
this down, though.) Another workaround is that some OpenGL 1.3 drivers
(nVidia) still support the multitexturing ARB extension, but others
(ATI) don't. This success with ctypes and the continued good things I
hear about Pyrex make me wonder if maybe the PyOpenGL build system
could be simplified by getting away from SWIG and using these two
technologies?
So, what's the story? Anyone know?

Mike,
I'm glad to see you're taking the bull by the horns...
> * Confirm that we've got all Mac-specific patches integrated and
> that we build on Mac OS X
The patches I've submitted have been working for Bob Ippolito and me
since late July, and since it seems a substantial majority of OS X
PyOpenGL users download their binaries from Bob, I reckon they're
working OK.
> * Get a build environment set up for Win32 so that we can produce
> 2.2.3 and 2.3 binary distributions on a computer with MSVC++
I've got access to MSVC 6.0 on Win2K, so I might be able to handle
this. I say "might" because I'm not an expert with Windows
compiling/linking issues, so if anything tricky arises, I'm not sure
what I'll be able to do. I would probably build the SWIG interfaces on
a different (*nix) machine (or, preferably, use those included with the
source).
Cheers!
Andrew

Well, I've given up on getting togl to work with Tkinter 8.4 under
Python 2.3, so given that no-one else has stepped up to the plate on
this one, I'm going to decree that we drop Togl support from PyOpenGL
versions for Python 2.3 and above. Honestly, I'd be happy to drop it
from all PyOpenGL 2.0.1 distributions, but that seems a little too
extreme this late in the game.
With that out of the way, we should look at releasing 2.0.1 (final) some
time over the next month. Here's what seems to be left to do:
* Confirm that we've got all Mac-specific patches integrated and
that we build on Mac OS X
* Document file-permission problem for Unix (need to set umask
before install)
* Decide whether glGet bug # 691935
(https://sourceforge.net/tracker/index.php?func=detail&aid=691935&group_id=5988&atid=105988)
is real, is going to get fixed, needs to be transferred to someone
else, or what
* Figure out what the solaris/sun-os build issues are, and whether
we can integrate a patch for them
* Document problems with togl and gle's use of malloc.h for FreeBSD,
possibly provide a patch to work around it, I assume this is
trivial for someone on BSD to create, I just don't know what it
requires. I'm not planning to integrate it into 2.0.1 as it's all
part of libraries we are, up to this point, just including unmodified.
* Get a build environment set up for Win32 so that we can produce
2.2.3 and 2.3 binary distributions on a computer with MSVC++
* Test RPMs on more than just Red Hat 8.0 (where they are created)
You may imagine that since I have no Mac, FreeBSD or Solaris machines on
which to test, some of those items will need a little feedback. We'll
have to see if we've got anyone still interested in doing the binary
builds for win32. Won't hold up the release for that, but would be nice
to have them available on the release day if possible.
My time this month is very limited, but I'll try to get at least one
full day to work on a PyOpenGL release, likely the weekend after this
one. It would be good if, before then, I had any feedback regarding
what's outstanding, what's critical for us to move forward, what issues
people have, etceteras.
Enjoy yourselves,
Mike
_______________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/

Patches item #805324, was opened at 2003-09-12 14:55
Message generated for change (Comment added) made by shane_holloway
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=805324&group_id=5988
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
>Assigned to: Tarn Weisner Burton (twburton)
Summary: McMillian Installer and "version" file
Initial Comment:
After fiddling with the McMillian Installer
(http://www.mcmillan-inc.com/install5_intro.html) and
my little PyOpenGL client application, I found what was
causing the OpenGL import to fail -- the reading of the
"version" file in the root of the package.
If you are not familar with the McMillian Installer, it
effecitvely zips up all modules and packages your
application is dependent upon, and packs that
information to the tail end of an executable file. It
does this by detecting all imports and also has a
mechanism for adding modules manually. However, it
does not have a mechanism for detecting or including
standard files in the fashion that OpenGL/__init__.py
file is using. So therefore, it has trouble importing
OpenGL in the McMillian Installer, and thus my patch. :)
There are a few ways in which we can accomplish fixing
this problem.
1. We could hard code the version number in the
__init__.py (yuck! -- that's why there is a "version"
file in the first place)
2. We can do a try/except block around the reading of
the file. (what value does OpenGL.__version__ get when
this error occurs? If we set it to some default value,
this potentially changes the behavior of any version
dependent code in the application. This is
undersierable... I like things to work the same in or
out of the packaging.
3. We can rename "version" to "__version__.py", change
the syntax slightly, and change the "__init__.py" file
to deal with those new changes. (This allows packaging
implementations like Installer and cx_Freeze detect the
import and include it in the packaging.)
I like the 3rd option the best, and thereby have
created a patch to implement that feature.
----------------------------------------------------------------------
>Comment By: Shane Holloway (shane_holloway)
Date: 2003-09-12 14:58
Message:
Logged In: YES
user_id=283742
Sorry, I could not figure out how to get the file to be in
the patch without adding it to cvs first... What's the
magic phrase? Anyhow, this file should complement the patch
by going into PyOpenGL2/OpenGL/__version__.py
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=805324&group_id=5988

Patches item #805324, was opened at 2003-09-12 14:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=805324&group_id=5988
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Nobody/Anonymous (nobody)
Summary: McMillian Installer and "version" file
Initial Comment:
After fiddling with the McMillian Installer
(http://www.mcmillan-inc.com/install5_intro.html) and
my little PyOpenGL client application, I found what was
causing the OpenGL import to fail -- the reading of the
"version" file in the root of the package.
If you are not familar with the McMillian Installer, it
effecitvely zips up all modules and packages your
application is dependent upon, and packs that
information to the tail end of an executable file. It
does this by detecting all imports and also has a
mechanism for adding modules manually. However, it
does not have a mechanism for detecting or including
standard files in the fashion that OpenGL/__init__.py
file is using. So therefore, it has trouble importing
OpenGL in the McMillian Installer, and thus my patch. :)
There are a few ways in which we can accomplish fixing
this problem.
1. We could hard code the version number in the
__init__.py (yuck! -- that's why there is a "version"
file in the first place)
2. We can do a try/except block around the reading of
the file. (what value does OpenGL.__version__ get when
this error occurs? If we set it to some default value,
this potentially changes the behavior of any version
dependent code in the application. This is
undersierable... I like things to work the same in or
out of the packaging.
3. We can rename "version" to "__version__.py", change
the syntax slightly, and change the "__init__.py" file
to deal with those new changes. (This allows packaging
implementations like Installer and cx_Freeze detect the
import and include it in the packaging.)
I like the 3rd option the best, and thereby have
created a patch to implement that feature.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=805324&group_id=5988