Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.011 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'configure': 0.05; 'problem?': 0.07; 'string': 0.09; 'pep': 0.09; 'prevents': 0.09; 'sure,': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'anyway': 0.14; 'windows': 0.15; 'check.': 0.16; 'concern,': 0.16; 'eliminating': 0.16; 'enough?': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'porting': 0.16; 'rebuild': 0.16; 'vendor)': 0.16; 'so.': 0.16; 'wrote:': 0.18; 'feb': 0.22; 'cc:addr:python.org': 0.22; 'builder': 0.24; 'questions:': 0.24; 'removed.': 0.24; 'skip': 0.24; 'cc:2**0': 0.24; 'second': 0.26; 'least': 0.26; 'values': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'function': 0.29; 'correct': 0.29; 'am,': 0.29; 'strongly': 0.30; 'vendor': 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; 'that.': 0.31; 'option.': 0.31; 'workaround': 0.31; 'option': 0.32; 'another': 0.32; 'linux': 0.33; '(most': 0.33; 'problem': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'version': 0.36; 'choosing': 0.36; 'ram': 0.36; 'changing': 0.37; 'so,': 0.37; 'skip:- 10': 0.38; 'short': 0.38; 'skip:_ 30': 0.39; 'does': 0.39; 'enough': 0.39; 'either': 0.39; 'according': 0.40; 'how': 0.40; 'easy': 0.60; 'problems.': 0.60; 'most': 0.60; "you're": 0.61; 'name': 0.63; 'decided': 0.64; 'our': 0.64; 'different': 0.65; 'fire': 0.65; 'relatively': 0.65; 'default': 0.69; 'certain,': 0.84; 'different.': 0.84; 'internally.': 0.84; 'pain': 0.84; 'subject:skip:_ 30': 0.84; 'to:none': 0.92 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=Khxl+moXGnMHXkN2hf6leEjZRpMjBlnd0orsTBS60V8=; b=gFIhe1E1rSh0DXpSTWHKxR4hp6UV3TJQoO+8R6NBa7oqgalkoUc00zPLhnVHjoJwfV 55fEmk4BgrYEf7C9eAt3Xvedog3utyva9TaduP1ojFrfP0D0u8ZQUu9kMVuJ4gx4Wb23 Cg9CpR9N294uRPCALHXMGiQdWZ8q43G6gU9cQRYDp0QyamscA5gJk34jHObHLkVUK5EB kdeJ+sKsqoevd0/p15OEpwQrmunesO6d8LgpWLofgDw8JM5e/aOxoMXDHX2WJn/4iuhF RYM2RKsGIes1Bx3VoPrqU+/AX+kO+bLXAfIApLZV59tuTmXyXDP3s7+5bTvyiqbqGrBM ikVg== MIME-Version: 1.0 X-Received: by 10.68.201.10 with SMTP id jw10mr39050216pbc.25.1391452028591; Mon, 03 Feb 2014 10:27:08 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 05:27:08 +1100 Subject: Re: undefined symbol: _PyUnicodeUCS4_AsDefaultEncodedString From: Chris Angelico Cc: Python Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 40 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1391452037 news.xs4all.nl 2940 [2001:888:2000:d::a6]:56052 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:65357 On Tue, Feb 4, 2014 at 4:41 AM, Skip Montanaro 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