Hi Mike. After another day of fiddling (including a new build of Python using --enable-uncode=ucs4) I've decided to return to my barely working installation and generate plots on a separate machine. I tried removing /usr/local and it caused more trouble than progress. I've got to get some results asap so will return to this problem once I can perform all my calculations on another machine.
Until then, thanks for the tips! Best regards, Mark. Michael Droettboom wrote: > mark starnes wrote: >> Hi Mike, thanks for responding. >> >> I spent most of last night with this, re-installing Python using SuSE's >> package manager, re-installing matplotlib the same way. No joy. I >> tried downloading the matplotlib source and found that when I attempted >> to install, setup.py claimed I didn't have gtk available as a Python >> import. Checking this, I found it to be true although the installation >> directories are present. Re-installing gtk and things that depended on >> it had no effect - it still wont import. >> >> Checking another machine, I found it worked ok with gtk, pylab and >> anything else I could test. The file versions and directory structures >> were the same. >> >> Following your UCS2 / UCS4 comments and a scroogle search, I found this: >> >> http://copia.ogbuji.net/blog/2006-01-09/Confusion_ >> >> sys.maxunicode is set to 65535 on the non-working installation. >> sys.unicode is set to 1114111 on the working installation! How did they >> become different? How can I get them to match? >> > The one that returns 65535 is 16-bit UCS2. That probably was built from > source, since most Linux distributions ship Python as UCS4. >> Checking sys.prefix on both installations shows the working machine to >> be '/usr', the non working, '/usr/local'. >> > That's another good data point. The non-working one was built from > source, and not from an installed SuSE package. >> $ whereis python >> Generates thirteen results on the working installation, one of which >> refers to a /local/ type entry. The non-working installation shows >> fifteen entries, five of which contain '/local/. >> > What's most important is what comes first, because that's what will run > when you simply type 'python'. (And sys.prefix tells you that, too). > > These are all clues without a definitive answer, but I'd put my money > on: you have a source-built Python sitting around in /usr/local which > can not access and is incompatible with all of the package-installed > stuff you have. >> To be honest, I'm lost. I'd like to remove Python and re-install it, >> with all the modules I'm now using. Removing it with SuSE's package >> manager generates all sorts of problems with dependencies. Updating it >> has no effect. Is there a way to convince the system to start afresh >> (assuming that's the best approach), maybe removing the local settings? >> > There's probably hundreds of crucial things that depend on Python, which > is why removing it causes all of the dependency problems. > > I almost feel guilty saying this, but if you don't want to keep anything > you've built from source (including non-Python stuff), you could > *backup* and then remove your /usr/local folder. I can't stress the > backup part enough ;) Then you should (most likely) only be dealing > with stuff installed from SuSE packages. Uninstalling things built from > source is usually not directly possible without using a tool like > checkinstall. > > You may also want to make sure that the PYTHONPATH environment variable > isn't set to anything. That will affect where Python libraries are > loaded from, and if you want to be in a "default" situation, it should > be unset. > > Cheers, > Mike >> >> Michael Droettboom wrote: >> >>> I recently ran into a similar problem myself building stuff from source, >>> but I'm not sure of the specifics with SuSE and their packages etc. >>> >>> Python can be configured in two ways -- with two-byte (UCS2) or >>> four-byte (UCS4) Unicode characters. Apparently the default for a >>> source installation of Python is UCS2, but many (most) Linux >>> distributions build it for UCS4. Python extensions built for one >>> configuration can not be used with a Python built for the other >>> configuration. >>> >>> When Python extensions are built, if all goes well, they will match the >>> configuration of the Python interpreter. It looks like somehow you have >>> a mismatch between matplotlib and your Python interpreter. >>> >>> If you installed everything from packages, I would expect them all to >>> match (unless SuSE's quality control has really gone down as of late >>> ;). Perhaps something is still around from when you built things from >>> source. Did you at any point build your own Python? >>> >>> On a number of Linux distributions (probably including SuSE, but I don't >>> know for sure), things installed from source are under the /usr/local >>> tree. To diagnose this, you could see if anything is getting pulled in >>> from there (rather than from the packaged stuff, which wouldn't be under >>> /usr/local). For instance "whereis python", will tell you which python >>> is being used. When you import a Python module, you can use __file__ to >>> see where it was imported from. For example: >>> >>> >>>>>> import pylab >>>>>> pylab.__file__ >>>>>> >>> Hope that at least offers some next steps for tracking this down. >>> >>> Cheers, >>> Mike >>> >>> mark starnes wrote: >>> >>>> Hi everyone, >>>> >>>> I'm running Suse10.2 and installing packages using Yast (after much >>>> pain >>>> trying to install Numpy and Scipy without it!). After installing (and >>>> re-installing) Matplotlib in this way, I get the error, >>>> >>>> ImportError: matplotlib/ft2font.so: undefined symbol: >>>> PyUnicodeUCS4_GetSize >>>> >>>> when I attempt to import pylab. >>>> >>>> Can anybody help me fix this? I couldn't find any help on the >>>> matplotlib site and my .matplotlib directory is empty. >>>> >>>> Oh, I'm also a bit new to Linux - please be patient! >>>> >>>> Thanks in advance, >>>> >>>> Mark. >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> This SF.net email is sponsored by DB2 Express >>>> Download DB2 Express C - the FREE version of DB2 express and take >>>> control of your XML. No limits. Just data. Click to get it now. >>>> http://sourceforge.net/powerbar/db2/ >>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Matplotlib-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>>> >>> > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
