Installing on Ubunutu 7.10

Is this a right version to download? Gutsy Installer If it is, then it installs correctly, or at least with no errors, but it’s not on my path (sys.path) Where is Panda3D installed to, and if I just use sys.path.append(installation location) will that work?

Edit: Treeform posted a minute before, and that appears to be the version I have downloaded. That’s the version I was referring to in the original post.

jpw27: ubuntu and debian are different from each other. Earlier, you said you were using ubuntu, not debian. So don’t download the debian package. Download the ubuntu package.

Use the link that treeform provided, above.

panda3d ubutnu gusty 386 DEB
DEB being the debian packedge so we are left with python issues
have you tried both python24 and python25 and both did not get panda3d paths?

Okay, I was using debian to refer to it being a .deb package. Sorry for the confusion. I edited my other posts so it’s clearer.

Anyway, just to be complete, here’s the output of print sys.path in both 2.4 and 2.5

jason@jason-ubuntu:~$ python2.4
Python 2.4.4 (#2, Mar  7 2008, 04:45:43) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
['', '/usr/lib/', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages/Numeric', '/usr/lib/python2.4/site-packages/gst-0.10', '/var/lib/python-support/python2.4', '/usr/lib/python2.4/site-packages/gtk-2.0', '/var/lib/python-support/python2.4/gtk-2.0']
jason@jason-ubuntu:~$ python2.5
Python 2.5.2 (r252:60911, Mar  9 2008, 19:54:30) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg', '/usr/local/lib/python2.5/site-packages/PyOpenGL-3.0.0b1-py2.5.egg', '/usr/local/lib/python2.5/site-packages/OpenGLContext-2.1.0a2-py2.5.egg', '/usr/local/lib/python2.5/site-packages/PyVRML97-2.2.0a1-py2.5-linux-i686.egg', '/usr/local/lib/python2.5/site-packages/PyDispatcher-2.0.1-py2.5.egg', '/usr/local/lib/python2.5/site-packages/FontTools_numpy-2.1a1-py2.5-linux-i686.egg', '/usr/local/lib/', '/usr/local/lib/python2.5', '/usr/local/lib/python2.5/plat-linux2', '/usr/local/lib/python2.5/lib-tk', '/usr/local/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/local/lib/python2.5/site-packages/PIL']

Thanks for the help guys, sorry to be a pain.

Well, it’s pretty clear from looking at those paths that something went wrong. Panda3D isn’t fully installed. I don’t know why.

I’m going to rev up my gutsy machine and see if I can analyze the situation a little bit. I’ll report back in a little while.

[update] OK, I’m back. Here’s what I have to report:

  • It installs correctly on my gutsy box.

  • My gutsy box uses python 2.5.

  • The deb package installs a file /usr/lib/python2.5/site-packages/panda3d.pth

On my machine, that pth file causes panda to be inserted into the python path. It doesn’t seem to be working on your machine. So my question would be: is that file present on your machine?

If it isn’t present, we have to figure out why the DEB package didn’t get fully extracted. If it is present, we have to figure out why your copy of python isn’t responding to the presence of pth files.

Yep, panda.pth is there with the contents
Is that identical to yours? If so, this appears to be a Python problem, and I can go ask somewhere with Python support. Also, would sys.path.append("/usr/share/panda3d") and sys.path.append(“usr/lib/panda3d”) do the trick? I thought I tried this earlier, but then when I opened up another shell it hadn’t stuck. Thanks for all the help.

That is indeed what’s supposed to be in there.

Go ahead and try appending those directories to sys.path. It might work. But it still raises the question of why the PTH file isn’t working. I’d like to know the answer to that - if you find out, please tell me.

On your installation is panda3d.pth a link? Every other .pth file is, but not panda3d.pth. If so, what does it link to?

Since using sys.path.append() from the interpreter didn’t appear to be persistent, I tried another tactic. However, adding sys.path.append(’/usr/share/panda3d’) to doesn’t work either. Although it appears their isn’t a direct.directbase.DirectStart. Under /usr/share/panda3d there is direct/src/directbase/DirectStart, but adding .src didn’t solve it.

I leave town for a week at 3:30 this morning, but when I get back hopefully I can solve this.

EDIT: It struck me that I put sys.path.append after import direct. I put import sys, sys.path.append() before that, and it appears to have worked, but now it throws me different errors.

DirectStart: Starting the game.
Traceback (most recent call last):
  File "", line 16, in <module>
    import direct.directbase.DirectStart
  File "linuxroot/usr/share/panda3d/direct/src/directbase/", line 3, in <module>
  File "linuxroot/usr/share/panda3d/direct/src/showbase/", line 10, in <module>
  File "/usr/share/panda3d/pandac/", line 1, in <module>
    from libpandaexpressModules import *
  File "/usr/share/panda3d/pandac/", line 1, in <module>
    from extension_native_helpers import *
  File "/usr/share/panda3d/pandac/", line 38, in <module>
    from libpandaexpress import *
ImportError: /usr/lib/panda3d/ undefined symbol: PyUnicodeUCS4_AsWideChar

This is the error that made me give up on Python-Ogre. Anybody here know anything about it?

That file is just a file, not a symbolic link. And yes, you’re right, the other pth files in that directory are symbolic links… interesting. But it should work as a simple file.

It’s something to do with the Unicode size Python is encoded in, however, I recompiled Python in a different size as kind of guest work, and it threw me the error except this time with PyUnicodeUCS2 instead of PyUnicodeUCS4.

This deserves an emoticon… :frowning:

Did you ever try just adding the paths to sys.path?

With sys.path.append()? It wasn’t persistent, or at least how I was doing it wasn’t. Every time I Ctrl+D’ed out of Python, the next time I went back in the sys.path wasn’t with the things I appended. I need to research this Unicode problem a little deeper, and hope it doesn’t mean a recompile of Python.

I wonder if you saw my post above…(?) I posted after you, but I had started writing before you so it went it above you.

Truthfully, I’ve never dealt with unicode. Don’t know anything about it. I don’t see any reason to think that this is a unicode problem… it seems more like a configuration file problem to me. As in, somebody told python not to read PTH files. Or maybe, somebody told python not to read PTH files unless some condition was met. Not sure, but that’s the general feel I get.

I was googling around and I found this:

It sounds vaguely related.

Try an experiment: move the pth file from /usr/lib/python2.5/site-packages to /usr/lib/python2.5, and see if that makes any difference.

I was referring to PyUnicodeUCS4, which is a unicode error, and occurred after I worked around the import error by putting sys.path.append() in front of the other import statements in the Asteroids tutorial. I see no reason in trying to fix the path files if it’s just going to give me Unicode errors when I fix them.

Basically, I added
import sys
sys.path append(’/usr/lib/panda3d’)
to the top of the Asteroids example in samples. Now I don’t get an import errors, but it complains about Unicode, which is an error I’ve experienced before but never resolved (see two or three posts above for more information)

I’ve got a flight in a couple hours though, be back in a week to try and fix this

I’m going to update my copy of ubuntu and see if I can get my own to break.

OK, here’s what I can tell you.

Panda3D uses the function ‘PyUnicode_AsWideChar’. This function is supposed to be supplied by the python library.

In my copy of ubuntu gutsy, there’s a configuration file called “/usr/include/python2.5/pyconfig.h” which contains this line:

#define Py_UNICODE_SIZE 4

This, in turn, causes Py_UNICODE_WIDE to be defined. That, in turn, causes this to happen:

#define PyUnicode_AsWideChar PyUnicodeUCS2_AsWideChar
#define PyUnicode_AsWideChar PyUnicodeUCS4_AsWideChar

Since the ubuntu gutsy Panda3D distribution was compiled using this copy of python, when it calls PyUnicode_AsWideChar, it’s really calling PyUnicodeUCS4_AsWideChar.

My theory is this: your copy of python was compiled with Py_UNICODE_SIZE 2. You can probably check this by looking in your copy of pyconfig.h. If that’s the case, then that would explain why your copy of python isn’t providing this function.

So how did this happen? My guess is that your sources.list contains a non-ubuntu source, and that as a result, you’ve accidentally installed a copy of python other than the standard ubuntu python.

  • Josh

Don’t ask me why this didn’t work before, because I’m almost positive I’ve tried it, but here’s what I did.

(If you wouldn’t mind, you might want to add some of this to the wiki, I see you have added the part about the error message)
I deleted my Python installation in /usr/local, downloaded the newest stable (2.5.2), ran ./configure --enable-unicode=ucs4 then make and make install. After this, run “python” and see if the version/date built make sense. Then, do the following

import sys
if sys.maxunicode > 65535:
    print 'UCS4 build'
    print 'UCS2 build'

If this comes out to UCS4, you’re good. Then create /usr/local/lib/python2.5/site-packages/panda3d.pth with the two lines “/usr/share/panda3d” and “/usr/lib/panda3d”. Then go back to an interpreter and do sys.path and make sure they’re there. Then the demos worked.

Well, I don’t know how many possible ways two copies of python can be different from each other. Obviously, they can differ in their major version numbers (ie, 2.4 versus 2.5), they can differ in their bit-sizes (32 bits versus 64 bits), and they can also differ in their unicode configurations (UCS2 versus UCS4), but who knows if that’s all.

Long story short, python libraries need to be compiled for a particular variant of python. Install a different variant, and Panda3D isn’t going to work.

Update: here’s what I added to the manual, under Linux Installation:

Python packages need to be compiled for a particular variant of python. For example, a package that works with python 2.4 will not work with python 2.5. A package that works with 32-bit python will not work with 64-bit python. A package that works with UCS2 python will not work with UCS4 python. And so forth. In short, a python package must be carefully aligned, feature-for-feature, with one particular python interpreter. That package will not work with any other python interpreter.

Fortunately for you, our prepackaged copies of Panda3D are already carefully matched. For example, our Panda3D for Ubuntu Gutsy Gibbon is already perfectly matched to the python interpreter that comes with Ubuntu Gutsy Gibbon. So normally, you don’t need to worry about this at all.

If your Linux Distribution is not listed, you will need to build your own copy of Panda3D. This is not very difficult, the Panda3D build process tends to work out-of-the box. But trying to use an RPM or a DEB from some other Distribution is very unlikely to work, because of this need for an exact feature-for-feature match between the python package and the python interpreter.

If you are using a copy of python other than the one that came with the Linux Distribution, you have a bigger problem. Panda3D’s build-scripts automatcially build Panda3D for the system’s native python interpreter, not for some other python interpreter. To get Panda3D to build for some other python interpreter, you will have to edit the build scripts.

As much as the 20 prior posts would beg to differ, getting this fixed was actually pretty simple, it just entailed recompiling Python with a Unicode flag. Finding the problem was difficult, but the solution is simple. So this error really, as far as I can tell, isn’t that big a deal. ./configure --enable-unicode=ucs4 is the answer. I’m not sure what I did to have a UCS2 build, but anyone getting this error, it’s about a 1 step fix.

Just because I don’t feel this deserves a new topic: I just tried to install Panda 1.5 and GDebi told me I had a later version already installed. Unless this is a known/easy issue, I don’t mind, since 1.4 is working.