undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString

Skip Montanaro skip at pobox.com
Mon Feb 3 19:59:42 CET 2014

On Mon, Feb 3, 2014 at 12:27 PM, Chris Angelico <rosuav at gmail.com> wrote:
> 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.

Thanks. I get 65535 for our vendor-built Python, and 1114111 from
/usr/bin/python. So (no great surprise), it looks like our vendor is
to blame.

> 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.

I'm not concerned about that, certainly not in the immediate term.
/usr/bin/python and VTK appear to agree on this stuff. I trust Kitware
and the OpenSuSE people to take care of these sorts of problems if VTK
ever supports Python 3.x.


More information about the Python-list mailing list