Some test fail on my new Python 2.6
sxn02 at yahoo.com
Wed Apr 8 17:14:36 CEST 2009
Thanks for the pointers.
Here are some answers:
> Ok, so DBM wasn't built because it couldn't find the external symbol
> 'dbm_firstkey'. I have no idea off the top of my head why that would
> happen, but I don't think you really care at the moment since you are
> trying to get tkinter working. If you do care we can come back to that.
Although I can live without it, I do use sometime dbm. And then, again,
there are other ways to accomplish the same, so it's not critical.
>> building '_tkinter' extension
>> gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -DWITH_BLT=1 -I/usr/X11R6/include -I. -I/install/Python-2.6.1/./Include -I. -IInclude -I./Include -I/usr/local/include -I/install/Python-2.6.1/Include -I/install/Python-2.6.1 -c /install/Python-2.6.1/Modules/_tkinter.c -o build/temp.linux-i686-2.6/install/Python-2.6.1/Modules/_tkinter.o
>> gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -DWITH_BLT=1 -I/usr/X11R6/include -I. -I/install/Python-2.6.1/./Include -I. -IInclude -I./Include -I/usr/local/include -I/install/Python-2.6.1/Include -I/install/Python-2.6.1 -c /install/Python-2.6.1/Modules/tkappinit.c -o build/temp.linux-i686-2.6/install/Python-2.6.1/Modules/tkappinit.o
>> gcc -pthread -shared build/temp.linux-i686-2.6/install/Python-2.6.1/Modules/_tkinter.o build/temp.linux-i686-2.6/install/Python-2.6.1/Modules/tkappinit.o -L/usr/X11R6/lib64 -L/usr/X11R6/lib -L/usr/local/lib -lBLT -ltk8.5 -ltcl8.5 -lX11 -o build/lib.linux-i686-2.6/_tkinter.so
>> *** WARNING: renaming "_tkinter" since importing it failed: libtk8.5.so: cannot open shared object file: No such file or directory
> Now, this one is clear. It couldn't find libtk8.5.so when it tried to
> use _tkinter.so. So either that symlink doesn't exist, or points to a
> nonexistent library, or there's something wrong with your load library
> path, so that python isn't finding it when it tries to do the load.
> If you don't know what that last one means, check out 'man ldconfig'.
libpq.so.4 libtcl8.4.so libtclstub8.4.a libtk8.4.so libtkstub8.4.a python2.4 tcl8.4 tclConfig.sh tk8.5
libpq.so.4.0 libtcl8.5.so libtclstub8.5.a libtk8.5.so libtkstub8.5.a tcl8 tcl8.5 tk8.4 tkConfig.sh
>> test_multiprocessing skipped -- OSError raises on RLock creation, see issue 3111!
> According to the referenced bug, this may be a result of your not having
> /dev/shm mounted, but in any case it is more a bug in the tests than a
> bug in your system or setup.
/dev/hda3 on / type reiserfs (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
udev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,devmode=0664,devgid=85)
It's there, but if it is about a known bug in the test, maybe we should just ignore it?
>> test test_socket failed -- Traceback (most recent call last):
>> File "/install/Python-2.6.1/Lib/test/test_socket.py", line 474, in testSockName
>> my_ip_addr = socket.gethostbyname(socket.gethostname())
>> gaierror: [Errno -2] Name or service not known
> This probably means that you haven't properly defined 'localhost'
> in your /etc/hosts file.
# cat /etc/hosts
# This file describes a number of hostname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
# On small systems, this file can be used instead of a
# "named" name server. Just add the names, addresses
# and any aliases to this file...
# IPV6 versions of localhost and co
::1 ip6-localhost ip6-loopback
There is a localhost definition. Is it not correct?
>> test test_sys failed -- Traceback (most recent call last):
>> File "/install/Python-2.6.1/Lib/test/test_sys.py", line 354, in test_43581
>> self.assert_(sys.__stdout__.encoding == sys.__stderr__.encoding)
> This one is puzzling. Did you modify 'site.py'? Or perhaps you
> redirected stdout and stderr to different places and they
> wound up with different encodings for some reason. In which
> case that one would be a bug in the tests as well.
No, I didn't, nor have I done anything with stdout, stderror. When I ran the test, I did a make test | tee test.rez, which in my mind should have been harmless.
The output for individual test_httpservers was posted here:
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
More information about the Python-list