impressive does not work

[Michele Mordenti]

Binary package hint: impressive

System information:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu jaunty (development branch)
Release: 9.04
Codename: jaunty

uname -a
Linux monstermord 2.6.28-8-server #25-Ubuntu SMP Tue Feb 24 00:36:09 UTC 2009 i686 GNU/Linux

apt-cache policy impressive
impressive:
  Installato: 0.10.2r-2
  Candidato: 0.10.2r-2
  Tabella versione:
 *** 0.10.2r-2 0
        500 http://it.archive.ubuntu.com jaunty/universe Packages
        100 /var/lib/dpkg/status

Step to reproduce:
launch impressive

Error reported:
$ impressive packagingguide.pdf
Welcome to Impressive version 0.10.2
Traceback (most recent call last):
  File "/usr/bin/impressive", line 161, in <module>
    from OpenGL.GL import *
  File "/usr/lib/python2.5/site-packages/OpenGL/GL/__init__.py", line 2, in <module>
    from OpenGL.raw.GL import *
  File "/usr/lib/python2.5/site-packages/OpenGL/raw/GL/__init__.py", line 6, in <module>
    from OpenGL.raw.GL.constants import *
  File "/usr/lib/python2.5/site-packages/OpenGL/raw/GL/constants.py", line 7, in <module>
    from OpenGL import platform, arrays
  File "/usr/lib/python2.5/site-packages/OpenGL/platform/__init__.py", line 36, in <module>
    _load()
  File "/usr/lib/python2.5/site-packages/OpenGL/platform/__init__.py", line 27, in _load
    plugin_class = plugin.load()
  File "/usr/lib/python2.5/site-packages/OpenGL/plugins.py", line 14, in load
    return importByName( self.import_path )
  File "/usr/lib/python2.5/site-packages/OpenGL/plugins.py", line 28, in importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "/usr/lib/python2.5/site-packages/OpenGL/platform/glx.py", line 8, in <module>
    class GLXPlatform( baseplatform.BasePlatform ):
  File "/usr/lib/python2.5/site-packages/OpenGL/platform/glx.py", line 16, in GLXPlatform
    mode=ctypes.RTLD_GLOBAL
  File "/usr/lib/python2.5/site-packages/OpenGL/platform/ctypesloader.py", line 42, in loadLibrary
    return dllType( name, mode )
  File "/usr/lib/python2.5/ctypes/__init__.py", line 348, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: ('GL: cannot open shared object file: No such file or directory', 'GL', None)

[Michele Mordenti (micmord)]

workaround:
sudo aptitude install libgl1-mesa-dev

[Michele Mordenti (micmord)]

before installing libgl1-mesa-dev
~$ ls -l /usr/lib/libGL*
lrwxrwxrwx 1 root root 12 2009-02-24 08:18 /usr/lib/libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 395024 2009-02-23 16:36 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 2009-02-24 08:19 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.070300
-rw-r--r-- 1 root root 460432 2009-02-23 16:36 /usr/lib/libGLU.so.1.3.070300

With libgl1-mesa-dev installed
~$ ls -l /usr/lib/libGL*
lrwxrwxrwx 1 root root 10 2009-02-26 17:31 /usr/lib/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 12 2009-02-24 08:18 /usr/lib/libGL.so.1 -> libGL.so.1.2
-rw-r--r-- 1 root root 395024 2009-02-23 16:36 /usr/lib/libGL.so.1.2
lrwxrwxrwx 1 root root 20 2009-02-24 08:19 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.070300
-rw-r--r-- 1 root root 460432 2009-02-23 16:36 /usr/lib/libGLU.so.1.3.070300

[Lino Mastrodomenico (l-mastrodomenico)]

I've seen this problem with glchess, but I didn't want to install libgl1-mesa-dev.

The problem is that ctypes.util.find_library('GL') should return 'libGL.so.1' and instead returns None.

So an alternative workaround can be:

    from ctypes import util

    def find_library(name):
        fullname = find_library_orig(name)
        if fullname is None and name == 'GL':
            fullname = 'libGL.so.1'
        return fullname

    find_library_orig = util.find_library
    util.find_library = find_library

and then start the Python program with execfile(whatever), e.g. for me:

    execfile('/usr/games/glchess')

The root of the problem is that python-opengl should not call find_library every time a program is run, but it should hardcode a specific ABI version of the library it wants (e.g. 'libGL.so.1').

The Python ctypes documentation states:

"""
If wrapping a shared library with ctypes, it may be better to determine the shared library name at development type, and hardcode that into the wrapper module instead of using find_library to locate the library at runtime.
"""

[Pietro Battiston (toobaz)]

Can confirm on an updated jaunty