undefined symbol: PyUnicodeUCS4_FromEncodedObject

[Jeffrey Barish]

Robin Dunn wrote:

> The 111411 indicates it is using UCS4, if the value was 65535 then it
> would be UCS2.  That's on Dapper, so unless they've changed it to UCS2
> in Edgy for some reason there shouldn't be a need to rebuild anything.

Here's what I get:

$ python
Python 2.4.2 (#7, Sep 28 2005, 16:48:03)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxunicode
65535

It is strange also that the version regressed to 2.4.2 from 2.4.3.

> The UCS4/UCS2 issue is not the same.  That option controls what size a 
> character in a Python unicode object is, and also what related Python 
> APIs are available.  The wxPython ANSI/Unicode build options control 
> whether wxString is essentially an array of char or an array of wchar_t 
> values (where wchar_t may be two or four bytes depending on platform and 
> compiler.)

Yes, I understood that.  But I was thinking that if there were a wxPython
build for ansi, then it wouldn't be using either UCS4 or UCS2 and so would
work with any Python.

> Are you sure 
> that your current Python is the one from the APT repository and hasn't 
> been overwritten sometime in the past with another custom build?

I just installed the OS yesterday and I haven't done any custom builds on
the system, so the Python I am running is most likely the one that came off
the installation disc.  I actually installed RC1, but if they replaced
Python between the time I downloaded the iso on W and the official release
yesterday, then it seems to me I would be seeing it offered as an upgrade.

> If the Python in the repository has changed its build options (I guess I 
> should just upgrade one of my machines and check...) then the correct 
> thing to do is to rebuild wxPython.

I'll try that after I finish reinstalling the OS.
-- 
Jeffrey Barish