importing site fails - why?
stefan.sonnenberg at pythonmeister.com
Fri Nov 12 20:35:11 CET 2010
Am 12.11.2010 20:24, schrieb Helmut Jarausch:
> On Fri, 12 Nov 2010 19:42:46 +0100, Stefan Sonnenberg-Carstens wrote:
>> Am 12.11.2010 19:32, schrieb Helmut Jarausch:
>>> as often before, I've cloned a working system (GenToo) onto another
>>> machine. There, from a livecd and chroot to the cloned root partition
>>> python -v
>>> import site
>>> fails with the following error
>>> Python 2.6.6 (r266:84292, Oct 13 2010, 09:06:24) [GCC 4.4.4] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> dlopen("/usr/lib64/python2.6/lib-dynload/readline.so", 2); import
>>> readline # dynamically loaded from /usr/lib64/python2.6/lib-
>>>>>> import site
>>> # /usr/lib64/python2.6/site.pyc matches /usr/lib64/python2.6/site.py
>>> import site # precompiled from /usr/lib64/python2.6/site.pyc Traceback
>>> (most recent call last):
>>> File "<stdin>", line 1, in<module>
>>> File "/usr/lib64/python2.6/site.py", line 526, in<module>
>>> File "/usr/lib64/python2.6/site.py", line 509, in main
>>> known_paths = addsitepackages(known_paths)
>>> File "/usr/lib64/python2.6/site.py", line 289, in addsitepackages
>>> addsitedir(sitedir, known_paths)
>>> File "/usr/lib64/python2.6/site.py", line 185, in addsitedir
>>> addpackage(sitedir, name, known_paths)
>>> File "/usr/lib64/python2.6/site.py", line 159, in addpackage
>>> if not dircase in known_paths and os.path.exists(dir):
>>> File "/usr/lib64/python2.6/genericpath.py", line 18, in exists
>>> st = os.stat(path)
>>> TypeError: stat() argument 1 must be encoded string without NULL bytes,
>>> not str
>>> I'm puzzled and I'd appreciate any hints to the reason for this
>>> Many thanks,
>> You gave the answer yourself.
>> Chrooting does not automatically mean your SO cache is where it should
>> be for the target system.
>> Perhaps your livecd is newer/older than the target system or simply the
>> python in live environment
>> is not (most likely) compiled as the one in the target system.
> It has been working dozens of time!
> Are you saying, an ldconfig would rectify the situation?
> Unfortunately, I can only test it on monday.
It works as long as the so files are close enough in the way they were
the symbols they expose and the versions they have.
calling ldconfig _can_ help, but this is not for sure.
You can of course try to call
ldd /usr/bin/python (or where it lives)
to see if there is something abviously wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 231 bytes
Desc: not available
More information about the Python-list