Jason Vas Dias <[email protected]> added the comment:
Now I'm really confused.
After linked /usr/bin/python to python3.3 :
$ cd /usr/bin; rm -f python; ln -s python3.3 python;
the 2.7.1 build now succeeds !
(with the patched Lib/test/test_commands.py and the 'make test'
run as non-root ).
This time I don't get any build errors for missing modules
and don't have to edit Module/Setup .
BTW, the missing modules that caused the build to fail before
was :
'bsddb185 dl gdbm imageop'
; after the new ./python executable was built, it did some
'configure modules' stage which DID fail with these missing
modules, but now /usr/bin/python is python3.3, it DOESN'T fail.
I don't think the current state of the installed system python
should be able to affect in any way the build of a new python -
that to me is a fundamental, critical bug in the build system.
Maybe I should open a new bug on that issue ?
But yes, the issue of this specific bug is now closed -
python-2.7.1 now builds OK - but PLEASE, put these
lines or something like them in dlmodule.c :
#if __LONG_MAX__ > 0xffffffffU /* cpp -dM builtin : __LONG_MAX__ */
#error dlmodule only works in 32-bit mode.
#endif
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11946>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
