7:04 p.m.
After updating my F8 install with "yum update" I can't run yum anymore.
Here's the error I get:
"""
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/usr/lib/python2.5/lib-dynload/cPickle.so: undefined symbol:
PyUnicodeUCS4_DecodeRawUnicodeEscape
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.5 (trunk, Nov 28 2007, 11:58:41)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://wiki.linux.duke.edu/YumFaq
"""
It doesn't look like anyone else has this problem (or I would've seen
other reports..)
Running python in command line and importing cPickle doesn't work
(same/similar error).
I've tried reinstalling python from fedora rpm (same version) - to no avail.
SELinux is running in permissive mode (meaning it should not have
blocked anything while I was performing the yum update). There *was*
some error/warning message in yum - something to do with some selinux
flag no longer being used, but that's all.
Another clue: I've installed a self-compiled python in /usr/local.
However, I was careful to not make it conflict with the built-in
version: I used the configure option to give the executable a suffix (so
the executable has to be called as "python.foobar" instead of just
"python"). I've verified that running the different python installs used
different lib directories (so that should not have been a problem.)
I've also tried running my custom python and importing cPickle - that
works without a problem.
Any ideas?
I guess I could just replace cPickle.so with the custom-built one, but
I'm not sure that's the best course of action...
Will it even be compatible? I probably used compile flags different from
default.
8:21 p.m.
On 30/11/2007, Konstantin Svist wrote:
After updating my F8 install with "yum update" I can't run yum anymore.
I wonder why you chose a subject line like that when you broke Python
yourself? You even found the cause of it, didn't you?
Here's the error I get:
"""
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/usr/lib/python2.5/lib-dynload/cPickle.so: undefined symbol:
PyUnicodeUCS4_DecodeRawUnicodeEscape
That's provided by libpython (python-libs package).
I've tried reinstalling python from fedora rpm (same version) -
to no avail.
Another clue: I've installed a self-compiled python in
/usr/local.
Most likely you override LD_LIBRARY_PATH with /usr/local and your
self-built libpython in /usr/local/lib.
However, I was careful to not make it conflict with the built-in
version:
Apparently not careful enough. ;)
9:10 p.m.
Michael Schwendt wrote:
On 30/11/2007, Konstantin Svist wrote:
> After updating my F8 install with "yum update" I can't run yum
anymore.
>
I wonder why you chose a subject line like that when you broke Python
yourself? You even found the cause of it, didn't you?
> Here's the error I get:
>
> """
> There was a problem importing one of the Python modules
> required to run yum. The error leading to this problem was:
>
> /usr/lib/python2.5/lib-dynload/cPickle.so: undefined symbol:
> PyUnicodeUCS4_DecodeRawUnicodeEscape
>
That's provided by libpython (python-libs package).
> I've tried reinstalling python from fedora rpm (same version) - to no avail.
>
> Another clue: I've installed a self-compiled python in /usr/local.
>
Most likely you override LD_LIBRARY_PATH with /usr/local and your
self-built libpython in /usr/local/lib.
> However, I was careful to not make it conflict with the built-in
> version:
>
Apparently not careful enough. ;)
Okay, I'll try reinstalling the python-libs package.
According to rpm -q, the file is owned by "python-2.5.1.." package -
which is why I tried reinstalling that one, instead.
9:51 p.m.
On 30/11/2007, Konstantin Svist wrote:
Okay, I'll try reinstalling the python-libs package.
According to rpm -q, the file is owned by "python-2.5.1.." package -
which is why I tried reinstalling that one, instead.
You're misinterpreting the error message.
cPickle.so is included within the "python" package, but depends on
symbols in libpython in /usr/lib, which is found in the "python-libs"
package. It's important that you don't disturb this inter-library
dependency when installing into /usr/local/lib.
2:33 p.m.
Michael Schwendt wrote:
On 30/11/2007, Konstantin Svist wrote:
> Okay, I'll try reinstalling the python-libs package.
> According to rpm -q, the file is owned by "python-2.5.1.." package -
> which is why I tried reinstalling that one, instead.
>
You're misinterpreting the error message.
cPickle.so is included within the "python" package, but depends on
symbols in libpython in /usr/lib, which is found in the "python-libs"
package. It's important that you don't disturb this inter-library
dependency when installing into /usr/local/lib.
Well, that didn't work either - guess I f'ed it up pretty badly.
So far, I backed up /usr/lib/python-2.5 and overwrote cPickle.so from
/usr/local/... - yum stopped complaining about cPickle, but started
complaining about other libraries. After copying a few of those over as
well, it's now complaining about not being able to import sqlite (which
is weird, because it seems that python-sqlite2 package wasn't installed
in the first place)
I'll probably end up copying /usr/lib/python from a clean F8 system...
but I would really rather find the real cause of the problem and fix
that, instead.
By the way, the .so files had file creation date of Oct 30th - so it
doesn't look like they've been replaced... weird. I have noatime turned
on, but that shouldn't affect creation dates, right?
2:58 p.m.
On 30/11/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
Michael Schwendt wrote:
> On 30/11/2007, Konstantin Svist wrote:
>
>> Okay, I'll try reinstalling the python-libs package.
>> According to rpm -q, the file is owned by "python-2.5.1.." package -
>> which is why I tried reinstalling that one, instead.
>>
>
> You're misinterpreting the error message.
>
> cPickle.so is included within the "python" package, but depends on
> symbols in libpython in /usr/lib, which is found in the "python-libs"
> package. It's important that you don't disturb this inter-library
> dependency when installing into /usr/local/lib.
>
>
Well, that didn't work either - guess I f'ed it up pretty badly.
Yes, you did. :)
So far, I backed up /usr/lib/python-2.5 and overwrote cPickle.so
from
/usr/local/... - yum stopped complaining about cPickle, but started
complaining about other libraries. After copying a few of those over as
well, it's now complaining about not being able to import sqlite (which
is weird, because it seems that python-sqlite2 package wasn't installed
in the first place)
I'll probably end up copying /usr/lib/python from a clean F8 system...
but I would really rather find the real cause of the problem and fix
that, instead.
By the way, the .so files had file creation date of Oct 30th - so it
doesn't look like they've been replaced... weird. I have noatime turned
on, but that shouldn't affect creation dates, right?
Files installed as RPM packages get the mtime copied from what it
stored in the package. Python for F8 was last updated/built on Oct
30th.
1:31 a.m.
Michael Schwendt wrote:
On 30/11/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
> Michael Schwendt wrote:
>
>> On 30/11/2007, Konstantin Svist wrote:
>>
>>
>>> Okay, I'll try reinstalling the python-libs package.
>>> According to rpm -q, the file is owned by "python-2.5.1.." package
-
>>> which is why I tried reinstalling that one, instead.
>>>
>>>
>> You're misinterpreting the error message.
>>
>> cPickle.so is included within the "python" package, but depends on
>> symbols in libpython in /usr/lib, which is found in the "python-libs"
>> package. It's important that you don't disturb this inter-library
>> dependency when installing into /usr/local/lib.
>>
>>
>>
> Well, that didn't work either - guess I f'ed it up pretty badly.
>
Yes, you did. :)
> So far, I backed up /usr/lib/python-2.5 and overwrote cPickle.so from
> /usr/local/... - yum stopped complaining about cPickle, but started
> complaining about other libraries. After copying a few of those over as
> well, it's now complaining about not being able to import sqlite (which
> is weird, because it seems that python-sqlite2 package wasn't installed
> in the first place)
>
> I'll probably end up copying /usr/lib/python from a clean F8 system...
> but I would really rather find the real cause of the problem and fix
> that, instead.
>
> By the way, the .so files had file creation date of Oct 30th - so it
> doesn't look like they've been replaced... weird. I have noatime turned
> on, but that shouldn't affect creation dates, right?
>
Files installed as RPM packages get the mtime copied from what it
stored in the package. Python for F8 was last updated/built on Oct
30th.
After checking the system against a clean one and trying to copy some
things over, I tried removing the /usr/local install (by hand, since
uninstall is not really available with python source). That made
everything work.
Looking carefully at the filenames, I noticed that there were files
/usr/local/libpython2.5.so and /usr/local/libpython2.5.so.1.0 - and sure
enough, after bringing them back into /usr/local/lib/ things went back
to the broken state.
So:
* $LD_LIBRARY_PATH is not set
* I explicitly run /usr/bin/python
* "import sys; print sys.path" doesn't mention any /usr/local directories
* "import <some package that's only available in stock python>" works
* "import <some package that's only available in custom python>"
doesn't
work
So how come it seems to use /usr/local/lib/libpython2.5.so?? Where did I
go wrong?
7:08 a.m.
On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
After checking the system against a clean one and trying to copy some
things over, I tried removing the /usr/local install (by hand, since
uninstall is not really available with python source). That made
everything work.
Looking carefully at the filenames, I noticed that there were files
/usr/local/libpython2.5.so and /usr/local/libpython2.5.so.1.0 - and sure
enough, after bringing them back into /usr/local/lib/ things went back
to the broken state.
So:
* $LD_LIBRARY_PATH is not set
* I explicitly run /usr/bin/python
* "import sys; print sys.path" doesn't mention any /usr/local directories
* "import <some package that's only available in stock python>"
works
* "import <some package that's only available in custom python>"
doesn't
work
So how come it seems to use /usr/local/lib/libpython2.5.so?? Where did I
go wrong?
I've pointed out before that your local install of libpython is likely
the culprit, because the main python executable is linked against it
and binary modules (such as CPickle.so) depend on it, too. However, I
did not examine your run-time linker and python path configurations to
find out how exactly you installed private stuff to /usr/local.
Obviously, the /usr/local/bin/python binary contains different search
paths than /usr/bin/python. And with regard to the linker, even
without using LD_LIBRARY_PATH you can make available libraries in
/usr/local/lib via ld.so.conf*
You say you run /usr/bin/python, so print the output of "ldd
/usr/bin/python", please, when /usr/local/lib/libpython2.5.so is
available. Plus, the output of "python -c 'import sys; print sys.path'
".
1:40 p.m.
Michael Schwendt wrote:
On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
> After checking the system against a clean one and trying to copy some
> things over, I tried removing the /usr/local install (by hand, since
> uninstall is not really available with python source). That made
> everything work.
> Looking carefully at the filenames, I noticed that there were files
> /usr/local/libpython2.5.so and /usr/local/libpython2.5.so.1.0 - and sure
> enough, after bringing them back into /usr/local/lib/ things went back
> to the broken state.
>
> So:
> * $LD_LIBRARY_PATH is not set
> * I explicitly run /usr/bin/python
> * "import sys; print sys.path" doesn't mention any /usr/local
directories
> * "import <some package that's only available in stock python>"
works
> * "import <some package that's only available in custom python>"
doesn't
> work
>
> So how come it seems to use /usr/local/lib/libpython2.5.so?? Where did I
> go wrong?
>
I've pointed out before that your local install of libpython is likely
the culprit, because the main python executable is linked against it
and binary modules (such as CPickle.so) depend on it, too. However, I
did not examine your run-time linker and python path configurations to
find out how exactly you installed private stuff to /usr/local.
Obviously, the /usr/local/bin/python binary contains different search
paths than /usr/bin/python. And with regard to the linker, even
without using LD_LIBRARY_PATH you can make available libraries in
/usr/local/lib via ld.so.conf*
You say you run /usr/bin/python, so print the output of "ldd
/usr/bin/python", please, when /usr/local/lib/libpython2.5.so is
available. Plus, the output of "python -c 'import sys; print sys.path'
".
$ ldd /usr/bin/python
linux-gate.so.1 => (0x00110000)
libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
(0x00111000)
libpthread.so.0 => /lib/libpthread.so.0 (0x007f6000)
libdl.so.2 => /lib/libdl.so.2 (0x007ef000)
libutil.so.1 => /lib/libutil.so.1 (0x00d21000)
libm.so.6 => /lib/libm.so.6 (0x007c4000)
libc.so.6 => /lib/libc.so.6 (0x00669000)
/lib/ld-linux.so.2 (0x0064a000)
$ python -c 'import sys; print sys.path'
['', '/usr/lib/python25.zip', '/usr/lib/python2.5',
'/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk',
'/usr/lib/python2.5/lib-dynload', '/usr/lib/python2.5/site-packages',
'/usr/lib/python2.5/site-packages/Numeric',
'/usr/lib/python2.5/site-packages/PIL',
'/usr/lib/python2.5/site-packages/gst-0.10',
'/usr/lib/python2.5/site-packages/gtk-2.0']
When /usr/local/lib/libpython2.5.so is NOT available, I get this:
$ ldd /usr/bin/python
linux-gate.so.1 => (0x00110000)
libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x00111000)
libpthread.so.0 => /lib/libpthread.so.0 (0x007f6000)
libdl.so.2 => /lib/libdl.so.2 (0x007ef000)
libutil.so.1 => /lib/libutil.so.1 (0x00d21000)
libm.so.6 => /lib/libm.so.6 (0x007c4000)
libc.so.6 => /lib/libc.so.6 (0x00669000)
/lib/ld-linux.so.2 (0x0064a000)
2:44 p.m.
On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
$ ldd /usr/bin/python
linux-gate.so.1 => (0x00110000)
libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
Boom! As I wrote, your local lib install overrides the system lib,
which breaks badly if they are incompatible. If you want to avoid
that, you need to fix your ld.so* configuration.
3:58 p.m.
Michael Schwendt wrote:
On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
> $ ldd /usr/bin/python
> linux-gate.so.1 => (0x00110000)
> libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
>
Boom! As I wrote, your local lib install overrides the system lib,
which breaks badly if they are incompatible. If you want to avoid
that, you need to fix your ld.so* configuration.
So how do I "fix" it?
I'm guessing something in the process of compilation of /usr/local
version...
May be worthwhile mentioning:
on a 64bit install, python behaves differently: when LD_LIBRARY_PATH is
set to /usr/local/lib, it uses that library; when it's not set, it uses
/usr/lib64 version
4:54 p.m.
On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
Michael Schwendt wrote:
> On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
>
>> $ ldd /usr/bin/python
>> linux-gate.so.1 => (0x00110000)
>> libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
>>
>
> Boom! As I wrote, your local lib install overrides the system lib,
> which breaks badly if they are incompatible. If you want to avoid
> that, you need to fix your ld.so* configuration.
>
So how do I "fix" it?
I'm guessing something in the process of compilation of /usr/local
version...
In addition to not setting LD_LIBRARY_PATH is harmful ways, verify
/etc/ld.so* and kill your stuff in /usr/local until you know what
you're doing.
5:09 p.m.
Michael Schwendt wrote:
On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
> Michael Schwendt wrote:
>
>> On 01/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
>>
>>
>>> $ ldd /usr/bin/python
>>> linux-gate.so.1 => (0x00110000)
>>> libpython2.5.so.1.0 => /usr/local/lib/libpython2.5.so.1.0
>>>
>>>
>> Boom! As I wrote, your local lib install overrides the system lib,
>> which breaks badly if they are incompatible. If you want to avoid
>> that, you need to fix your ld.so* configuration.
>>
>>
> So how do I "fix" it?
> I'm guessing something in the process of compilation of /usr/local
> version...
>
In addition to not setting LD_LIBRARY_PATH is harmful ways, verify
/etc/ld.so* and kill your stuff in /usr/local until you know what
you're doing.
Hmm, sure enough - /etc/ld.so.conf contains "/usr/local/lib" (and the
64bit system doesn't)
Is it supposed to be there? If not, what could've added it? Is it safe
to remove?
Judging from contents of files in /etc/ld.so.conf.d/ it looks like every
[package/program/?] can define its own set of library paths. What's the
proper procedure for adding those?
2:52 a.m.
On 02/12/2007, Konstantin Svist <fry.kun(a)gmail.com> wrote:
>> So how do I "fix" it?
>> I'm guessing something in the process of compilation of /usr/local
>> version...
>>
>
> In addition to not setting LD_LIBRARY_PATH is harmful ways, verify
> /etc/ld.so* and kill your stuff in /usr/local until you know what
> you're doing.
>
Hmm, sure enough - /etc/ld.so.conf contains "/usr/local/lib" (and the
64bit system doesn't)
Is it supposed to be there?
No, it isn't. Unless you desperately want it to be there.
If not, what could've added it?
PEBKAC?
Is it safe to remove?
It depends on how you've modified your system.
Judging from contents of files in /etc/ld.so.conf.d/ it looks like
every
[package/program/?] can define its own set of library paths. What's the
proper procedure for adding those?
The default for Fedora is this:
$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf
6003
days inactive
6005
days old
13 comments
2 participants
participants (2)
-
Konstantin Svist -
Michael Schwendt