undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString

Chris Angelico rosuav at gmail.com
Mon Feb 3 20:09:33 CET 2014

On Tue, Feb 4, 2014 at 5:59 AM, Skip Montanaro <skip at pobox.com> wrote:
> 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.

That could be a problem, if you now need to have a complete
backward-incompatible Python replacement. Could be a bit of a pain for
all your other extensions. But it's worth doing if you have any chance
of ever seeing an astral character.

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

Okay. You mentioned the FSR, which is a 3.3 feature, so I thought I
may as well point out what the associated PEP says about that
particular function.

Good luck getting this fixed. Even if you do manage to get your vendor
to start shipping wide builds, you're going to have people screaming
about how much more RAM their processes use now :( Never mind that
other Linux builds of Python have done the same thing for years.


More information about the Python-list mailing list