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.

classification
Title: init_types() in Parser/asdl_c.py conflicts with init_types() in Modules/_typesmodule.c
Type: behavior Stage:
Components: Build Versions: Python 2.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, gsmecher, gvanrossum
Priority: normal Keywords:

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) * (Python committer) 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) * (Python committer) 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:30adminsetgithub: 46212
2008-01-23 21:37:42gsmechersetmessages: + msg61609
2008-01-23 21:33:12gvanrossumsetnosy: + gvanrossum
messages: + msg61607
2008-01-23 19:08:03brett.cannonsetstatus: open -> closed
resolution: not a bug
2008-01-23 18:54:34gsmechersetmessages: + msg61598
2008-01-23 18:32:22christian.heimessetpriority: normal
nosy: + christian.heimes
messages: + msg61596
2008-01-23 17:01:38gsmechercreate