Author Jason.Vas.Dias
Recipients Jason.Vas.Dias, georg.brandl, r.david.murray
Date 2011-04-30.11:48:25
SpamBayes Score 3.00337e-11
Marked as misclassified No
Message-id <1304164106.92.0.287722612757.issue11946@psf.upfronthosting.co.za>
In-reply-to
Content
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
History
Date User Action Args
2011-04-30 11:48:26Jason.Vas.Diassetrecipients: + Jason.Vas.Dias, georg.brandl, r.david.murray
2011-04-30 11:48:26Jason.Vas.Diassetmessageid: <1304164106.92.0.287722612757.issue11946@psf.upfronthosting.co.za>
2011-04-30 11:48:26Jason.Vas.Diaslinkissue11946 messages
2011-04-30 11:48:26Jason.Vas.Diascreate