New submission from Graeme Smecher:
On a BFLT (microblaze-uclinux) build of vanilla Python 2.5.1, "startup
-v" produces the following:
# python -v
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/local/lib/python2.5/site.pyc has bad mtime
import site # from /usr/local/lib/python2.5/site.py
# can't create /usr/local/lib/python2.5/site.pyc
# /usr/local/lib/python2.5/os.pyc has bad mtime
import os # from /usr/local/lib/python2.5/os.py
# can't create /usr/local/lib/python2.5/os.pyc
import posix # builtin
# /usr/local/lib/python2.5/posixpath.pyc has bad mtime
import posixpath # from /usr/local/lib/python2.5/posixpath.py
# can't create /usr/local/lib/python2.5/posixpath.pyc
# /usr/local/lib/python2.5/stat.pyc has bad mtime
import stat # from /usr/local/lib/python2.5/stat.py
# can't create /usr/local/lib/python2.5/stat.pyc
# /usr/local/lib/python2.5/UserDict.pyc has bad mtime
import UserDict # from /usr/local/lib/python2.5/UserDict.py
# can't create /usr/local/lib/python2.5/UserDict.pyc
# /usr/local/lib/python2.5/copy_reg.pyc has bad mtime
import copy_reg # from /usr/local/lib/python2.5/copy_reg.py
# can't create /usr/local/lib/python2.5/copy_reg.pyc
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
'import site' failed; traceback:
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site.py", line 62, in <module>
import os
File "/usr/local/lib/python2.5/os.py", line 696, in <module>
import copy_reg as _copy_reg
File "/usr/local/lib/python2.5/copy_reg.py", line 7, in <module>
from types import ClassType as _ClassType
File "/usr/local/lib/python2.5/types.py", line 93, in <module>
import _types
SystemError: _PyImport_FixupExtension: module _types not loaded
# /usr/local/lib/python2.5/warnings.pyc has bad mtime
import warnings # from /usr/local/lib/python2.5/warnings.py
# can't create /usr/local/lib/python2.5/warnings.pyc
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
import encodings # directory /usr/local/lib/python2.5/encodings
# /usr/local/lib/python2.5/encodings/__init__.pyc has bad mtime
import encodings # from /usr/local/lib/python2.5/encodings/__init__.py
# can't create /usr/local/lib/python2.5/encodings/__init__.pyc
# /usr/local/lib/python2.5/codecs.pyc has bad mtime
import codecs # from /usr/local/lib/python2.5/codecs.py
# can't create /usr/local/lib/python2.5/codecs.pyc
import _codecs # builtin
# /usr/local/lib/python2.5/types.pyc has bad mtime
import types # from /usr/local/lib/python2.5/types.py
# can't create /usr/local/lib/python2.5/types.pyc
import _types # builtin
Python 2.5.1 (r251:54863, Jan 23 2008, 09:07:29)
[GCC 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
This is happening because the autogenerated _PyImport_Inittab in
"Modules/config.c" (sensibly) contains the following startup definition:
/* This lives in Python/_types.c */
{"_types", init_types},
The problem is that two distinct init_types() exist, and the
microblaze-uclinux-gcc toolchain is picking up the wrong one.
On x86 GCC producing ELF binaries, the linker picks up the correct
init_types() defined in "Modules/_typesmodule.c". The above behaviour
does not occur, and the interpreter starts up successfully.
On Microblaze GCC producing BFLT binaries, the linker instead picks up
init_types() defined in "Python/Python-ast.c", which is autogenerated
from "Parser/asdl_c.py".
The obvious fix is to change one of the init_types() to something else.
I suspect this bug is related to Issue 1568243, which has been closed
(apparently a different fix was in order for PCs.) The doubly-defined
init_types() appears to still be present in the Subversion repository.
For reference, my cross-compiler is configured as follows:
$ microblaze-uclinux-gcc -v
Reading specs from
/lhome/gsmecher/petalinux-public/tools/linux-i386/microblaze-uclinux-tools/bin/../lib/gcc/microblaze-uclinux/3.4.1/specs
Configured with:
/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/srcs/gcc/configure
--target=microblaze-uclinux
--prefix=/home/jwilliams/PetaLogix/petalinux-test/toolchains/microblaze-uclinux/microblaze-uclinux-tools
--enable-languages=c,c++ --enable-multilib --enable-target-optspace
--with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99
--disable-clocale --disable-c-mbchar --disable-long-long
--enable-threads=posix --enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE
Thread model: posix
gcc version 3.4.1 ( PetaLinux 0.20 Build -rc1 050607 )
----------
components: Build
messages: 61589
nosy: gsmecher
severity: minor
status: open
title: init_types() in Parser/asdl_c.py conflicts with init_types() in
Modules/_typesmodule.c
type: behavior
versions: Python 2.5
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1917>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
