Issue1917
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2008-01-23 17:01 by gsmecher, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (5) | |||
---|---|---|---|
msg61589 - (view) | Author: Graeme Smecher (gsmecher) | Date: 2008-01-23 17:01 | |
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 ) |
|||
msg61596 - (view) | Author: Christian Heimes (christian.heimes) * | Date: 2008-01-23 18:32 | |
The compiler should not pick up the init_types function in Python/Python-ast.c. It's declared as static. The init_types function in Modules/_typesmodule.c is declared as extern so that's the real deal. It sounds more like a compiler or linker bug in the tool chain than a Python bug. |
|||
msg61598 - (view) | Author: Graeme Smecher (gsmecher) | Date: 2008-01-23 18:54 | |
Hm, sorry for the static -- you're absolutely correct, this has to be a compiler/linker/elf2flt bug. I'll patch my build instead of whining here. Thanks -- Feel free to close the report. |
|||
msg61607 - (view) | Author: Guido van Rossum (gvanrossum) * | Date: 2008-01-23 21:33 | |
The comment in config.c is wrong. If you still have a Python/_typesmodule.c file, something's wrong on your end! |
|||
msg61609 - (view) | Author: Graeme Smecher (gsmecher) | Date: 2008-01-23 21:37 | |
Hi Guido, Yup! From the tarball (Python-2.5.1.tgz), the actual comment (in Modules/config.c.in) reads: /* This lives in Python/_types.c */ {"_types", init_types}, ...which is different from the snippet I posted here (I hand-reverted my modifications, but got the comment wrong), but still incorrect (should be "Modules/_types.c".) cheers, Graeme |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:30 | admin | set | github: 46212 |
2008-01-23 21:37:42 | gsmecher | set | messages: + msg61609 |
2008-01-23 21:33:12 | gvanrossum | set | nosy:
+ gvanrossum messages: + msg61607 |
2008-01-23 19:08:03 | brett.cannon | set | status: open -> closed resolution: not a bug |
2008-01-23 18:54:34 | gsmecher | set | messages: + msg61598 |
2008-01-23 18:32:22 | christian.heimes | set | priority: normal nosy: + christian.heimes messages: + msg61596 |
2008-01-23 17:01:38 | gsmecher | create |