Confirmed: I compiled python with --enable-unicode=ucs4 (ucs2 was default) which fixed the problem.
Thank you, Hans Jørgen Kjærnet | Senior TD Storm Studios AS www.stormstudios.no w: +47 24 200 500 m: +47 93 027 843 2010/3/30 Phil Thompson <[email protected]>: > On Tue, 30 Mar 2010 15:08:15 +0200, Hans Jørgen Kjærnet > <[email protected]> wrote: >> Hi, >> >> As we are using different versions of python in our Studio, we would >> like sip to be installed into ONE common location. >> >> Here's a list of our pythons: >> python2.5.1 - compiled from repository and installed into a shared >> network location >> maya2009-python2.5.1 - The program we use for 3D (Autodesk Maya >> 2009)This is the python2.5.1 that comes with maya and resides under >> the maya location. It's a built in interpreter. >> nuke5.2-python2.5.1 - This is the python2.5.1 for nuke (The Foundry, >> Nuke). Also a built in interpreter. >> >> So, my initial thought was to compile and install sip (4.10.1) into >> one common site wide location (so there will be less maintenance), >> say: /net/share/python/site-packages, and have >> PYTHONPATH=/net/share/python/site-packages. >> >> However, sip will only work for the python interpreter that was used >> to compile sip. In this case, let's assume I'm using the self compiled >> python2.5.1 from the repository. When I try to import sip from inside >> maya or nuke, I get a "Undefined symbol: PyUnicodeUCS2_DecodeLatin1. I >> figure this is becasue it can't locate the libpython.so in the >> self-compiled python2.5.1. Setting LD_LIBRARY_PATH doesn't do the >> trick either - besides, I really don`t want to have LD_LIBRARY_PATH >> configured. >> >> I did install sip for each of the pythons, and it worked. This is what >> I would like to avoid as it presents an extra step of maintenance when >> dealing with upgrades. >> >> So, question: >> Is there a way to have the sip module shared between multiple >> instances of python interpreters - and if so - what's the best way to >> do this? FYI, PyQt works fine from a single site wide location. > > The likely problem is that your Python interpreters have been built > differently relating to how Unicode characters are stored. > > Phil > _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
