On Jan 28, 1:25 pm, "Alex Holkner" <[EMAIL PROTECTED]> wrote:
> On 1/28/08, Gary <[EMAIL PROTECTED]> wrote:
>
> > python -c 'import pyglet.clock'
> > Traceback (most recent call last):
> > File "<string>", line 1, in <module>
> > File "clock.py", line 165, in <module>
> > File "/usr/lib/python2.5/site-packages/pyglet/lib.py", line 44, in
> > load_library
> > return ctypes.cdll.LoadLibrary(path)
> > File "/usr/lib/python2.5/site-packages/ctypes/__init__.py", line
> > 395, in LoadLibrary
> > return self._dlltype(name)
> > File "/usr/lib/python2.5/site-packages/ctypes/__init__.py", line
> > 312, in __init__
> > self._handle = _dlopen(self._name, mode)
> > OSError: /usr/lib/libc.so: invalid ELF header
>
> This traceback doesn't make sense. The LoadLibrary call in lib.py is
> at lines 73 and 78, not 44. Both of these calls are inside try blocks
> that catch OSError (and then pass, so as to attempt the next search
> term). Why is your lib.py different?
Got it! I haven't tracked down all the particulars in what's
happening here, but I *can* cause it to work or fail at will. Alex
provided the clue here. That's an old version (from beta3 I think) of
lib.py being found in an installation of pyglet1.0.
(The clue was the line numbers and the claim that *both* LoadLibrary
calls are in try blocks -- in the code I patched only the first
LoadLibrary was in a try block. Clearly some version mismatch was in
play.)
To cause this error at will, install beta3 by copying by hand the
pyglet directory into /usr/lib/python2.5/site-packages. Then
install pyglet1.0 using "python setup.py install". Attempts to
import clock.py result in the error we've been chasing around on the
thread.
To fix: Delete the pyglet directory and egg from ../pyglet2.5/site-
packages and "python setup.py install". Then all is fine when
importing clock.py.
To add to the confusion, if beta3 is installed using "python setup.py
install", and then pyglet1.0 is installed the same way (and without
deleting the old version) then importing clock works as it should.
I'll leave it to someone else to work out how the installation over a
hand copied version failed, but I won't hand copy any more.
If you're curious as to the reason I hand-copied the pyglet directory
in the first place: Some suggestion in the README (or such) pointed
out that one can use pyglet without installing it at all -- just
setting PYTHONPATH to the directory containing the code is
sufficient. I worked that way for quite a while, while learning my
way around pyglet. When I got tired of setting PYTHONPATH, and was
convinced that pyglet was going to occupy a larger portion of my
projects, I simple moved that directory into site-packages. And all
worked fine until I installed pyglet1.0 (the proper way) over the top
of that.
Sorry to bother and annoy everyone...
Gary Herron
>
> Alex.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
