Home Original page

undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString

Chris Angelico rosuav at gmail.com
Mon Feb 3 13:27:08 EST 2014 
On Tue, Feb 4, 2014 at 4:41 AM, Skip Montanaro <skip at pobox.com> wrote:
> I think this means that at configure time, OpenSuSE and our vendor
> chose different values for the --enable-unicode option. Is that
> correct?

Easy enough to check. Fire up each Python and have a look at what
sys.maxunicode is - if it's 65535, you have a buggy-mode Python that
uses either UCS-2 or UTF-16 internally.

> If so, I have a few questions:
>
> 1. Is there a workaround short of rebuild one version of Python or the other?

I don't think so. What you're seeing may be a relatively
simple-looking error, but the internal representation of every single
string is different. Bound to cause problems.

> 2. Does the flexible string representation avoid this problem?

Well yes, by eliminating the option of a UCS-2 build altogether, the
FSR prevents the compatibility problem of some choosing it and some
not :)

> 3. Which builder (OpenSuSE or our vendor) decided the default wasn't
> good enough?

Not sure, but I would strongly recommend going for a wide build. It
may be a pain to use that much RAM everywhere, but at least you get
correct behaviour; and that's how most Pythons on Linux have been
(most Windows Pythons were built narrow).

But there is another concern, which your second point minorly touches
on. I'm not certain, but I think the name
_PyUnicodeUCS4_AsDefaultEncodedString means that VTK was built against
a wide Python ("UCS4") and calls _PyUnicode_AsDefaultEncodedString.
According to PEP 393, that function - which had always been internal
anyway - is completely removed. Porting VTK to Python 3.3+ will mean
changing that.

ChrisA
More information about the Python-list mailing list