Installing on Ubunutu 7.10

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:

bugs.python.org/issue1431

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/share/panda3d’)
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:

#ifndef Py_UNICODE_WIDE
#define PyUnicode_AsWideChar PyUnicodeUCS2_AsWideChar
#else
#define PyUnicode_AsWideChar PyUnicodeUCS4_AsWideChar
#endif

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'
else:
    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.