Jason Vas Dias added the comment:
The alternative is to use a "GCC Spec File" , such as
that printed by
$ gcc -dumpspecs
Here is one such I've used in the past to overcome similar problems:
$ cat /home/jason/local32.spec
*lib:
+ -lc_nonshared
*startfiles:
+ /lib32/cr
Jason Vas Dias added the comment:
Oops, cut myself off mid-sentence in that previous comment ... AIWS :
If you are on a RedHat derived system, where /lib/ld-linux.so.2 is
32-bit , you should be OK; if, however, you are on a Gentoo
derived or "my style" system, you need to make sure
Jason Vas Dias added the comment:
RE: msg137311 : Alex - you wrote :
> I'm recompiling this 32 bit python with the following commands:-
> $ export CFLAGS="-O2 -fPIC"
> $ export CXXFLAGS=$CFLAGS
> $ OPT=-m32 LDFLAGS=-m32 ./configure --prefix=$HOME/32
> Does that se
Jason Vas Dias added the comment:
so I can do:
$ setarch i686
$ strace -s8192 -e trace=execve /usr/bin/python
execve("/usr/bin/python", ["/usr/bin/python"], [/* 65 vars */]) = 0
execve("/usr/bin//32/python", ["/usr/bin//32/python"], [/* 66 vars */]) =
Jason Vas Dias added the comment:
RE: comment msg137266 - thanks for responding, Alex - though
don't get misled by that wrapper script I wrote, though - I
ended up replacing it with a short "C" program, which I'll attach
after this comment.
RE: > I think Python is awes
Jason Vas Dias added the comment:
final python wrapper script :
$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7.1}
ARCH=`uname -m`
CMD=''
case $ARCH in
i686)
CMD="/usr/bin/32/${ME}"
;;
*)
CMD="/usr
Jason Vas Dias added the comment:
Oops, thought there may be gotchas to that multi-arch python wrapper -
it wasn't quoting its arguments properly - here is now what I have as
/usr/bin/python :
$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH=`
Jason Vas Dias added the comment:
OK, the last two comment contained complete instructions for setting
up a working dual 64-bit + 32-bit python installation.
Final, working /usr/bin/python :
$ cat /usr/bin/python
#!/bin/sh
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH
Jason Vas Dias added the comment:
So to get python multi-arch working as I expect I'd have to wrap the C header:
/usr/include/python-2.7/pyconfig.h
with something like:
#ifdef __i386__
#include
#else
#include
#endif
and that's it ! After building i686-Python-2.7.1, I
Jason Vas Dias added the comment:
Aha ! Is the above multi-arch config what would result if I did :
--with-universal-archs=ARCH
select architectures for universal build
("32-bit",
"64-bit",
Jason Vas Dias added the comment:
BTW, while I'm here :
Any advice on how to setup a truly multi-architecture python installation?
I'm considering doing something like :
1. build same python source for both 32-bit and 64-bit, with
64-bit installing /usr/lib/python-$V as /usr/li
Jason Vas Dias 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 ).
Th
Jason Vas Dias added the comment:
RE: msg134751 - Thanks for responding, George -
This bug is still an issue for me, as even though I now have Python-3.3
having passed its test suite, installed and running OK, and even
went so far as to 'cd /usr/bin; rm -f python; ln -s python3.3 p
Jason Vas Dias added the comment:
One last niggle : when I do
$ DESTDIR=`pwd`/inst make install
The configure '--libdir=/usr/lib64' setting I specified is ignored
and python installs itself under /usr/lib . I guess I need to raise
a different b
Jason Vas Dias added the comment:
Nope, all tests except rpm dependant test_distutils OK as non-root
with the patch I submitted for #11956 - so I guess that's good
enough .
Please fix the python 'make test' to work when run as root u
Jason Vas Dias added the comment:
hmm... not sure if "make test" completely succeeds as non-root user yet:
"test_subprocess" has been sitting in this state for @ 30mins :
[282/354] test_subprocess
.
this bit of output is from a test of stdout in a different process
Jason Vas Dias added the comment:
argparse.py needs a similar fix, but I'm not sure where - I raised
issue #11955 on this .
--
___
Python tracker
<http://bugs.python.org/is
Jason Vas Dias added the comment:
OK, so those test_argparse.py and test_import.py tests succeed if run
as a non-root user , because as the super-user one is allowed to
override mode 0300 ( lack of 'w' bit for owner ) on a directory ,
so some tests that check if they are unable to cr
Jason Vas Dias added the comment:
Aha ! the test succeeds as a non root (super-) user .
This is because as a root user I can override w bit
settings on directories I own: see issue #11956
for fix I applied to test_import.py to fix same
issue. Thanks
Jason Vas Dias added the comment:
Aha ! Yes, the test DOES succeed as a non-root user , and yes,
if you are super user you can override any write bits in
directory permissions if you own the directory.
So the fix ? : skip 'unwritable_directory' test if you are root -
here&#
Jason Vas Dias added the comment:
oops, no sorry it was this bit from the strace log :
umask(0222) = 022
stat("./@test_9634_tmp", 0x7fff7ef64130) = -1 ENOENT (No such file or directory)
open("./@test_9634_tmp.cpython-33m.so", O_RDONLY) = -1 ENO
Jason Vas Dias added the comment:
So, in the statement that fails :
self.assertFalse(os.path.exists(os.path.join(...))) .
either self.assertFalse is failing or os.path.exists is failing
or os.path.join is failing.
The fact that the error message is 'AssertionError: True is not
Changes by Jason Vas Dias :
--
components: +Build
type: -> crash
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue11956>
___
___
Python-
New submission from Jason Vas Dias :
Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config
New submission from Jason Vas Dias :
Hi - I've been experiencing many errors trying to build any version
of Python that will pass its test suite - see issues : #11946 , #11954 -
and now I've been advised to raise bugs about each test failure -
hence this bug. For details of my config
Jason Vas Dias added the comment:
'make test' failures after
$ /usr/src/cypython/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
$ make -j2 && make test
(make test fails)
So, to run in "verbose mode", I do :
$ LD_LIBRARY_PATH=`pwd` LD_PRELOAD=`pwd`/lib
Jason Vas Dias added the comment:
OK, so the ' vanilla configure ' build succeeds too - using DB module
only gdbm , and with internal libffi:
$ make clean
$/usr/src/cpython/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared
...
$ echo $?
0
$ make -j2
...
$ echo $?
0
But e
Jason Vas Dias added the comment:
In reply to last comment :
RE: > a single, focused bug
What is this bug if not single and focused ?
The "SINGLE FOCUS" of this bug, in case you missed it , is that
there appears to be no source release of python that can build
and pass its mak
Jason Vas Dias added the comment:
[237/354] test_pyexpat
test_ordered_attributes (test.test_pyexpat.SetAttributeTest) ... ok
test_specified_attributes (test.test_pyexpat.SetAttributeTest) ... ok
test_parse_file (test.test_pyexpat.ParseTest) ... ok
test_unicode (test.test_pyexpat.ParseTest
Jason Vas Dias added the comment:
test_too_high_from_package (test.test_import.RelativeImportFromImportlibTests)
... test test_import failed -- Traceback (most recent call last):
File "/usr/src/cpython/Lib/test/test_import.py", line 545, in
test_unwritable_directory
&#
Jason Vas Dias added the comment:
test_start_with_double_slash
(test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ...
/usr/src/cpython/Lib/unittest/case.py:799: BytesWarning: str() on a bytes
instance
(i, item1, item2))
test test_httpservers failed -- multiple errors occurred
ok
Jason Vas Dias added the comment:
test_successes_one_group_sysargs (test.test_argparse.TestTypeUserDefined) ...
test test_argparse failed -- multiple errors occurred
ok
==
FAIL: test_failures_many_groups_listargs
Jason Vas Dias added the comment:
[ 16/354] test_argparse
... # all ok up to:
test_wb_1 (test.test_argparse.TestFileTypeRepr) ... ok
test_failures_many_groups_listargs (test.test_argparse.TestFileTypeW) ... FAIL
test_failures_many_groups_sysargs (test.test_argparse.TestFileTypeW) ... FAIL
Jason Vas Dias added the comment:
OK, so getting out strace shows I need to do :
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython3.3.so.1.0 ./python -Wd -E
-bb /usr/src/cpython/Lib/test/regrtest.py -l -v 2>&1 | tee
make.test.verbose.log
I'll show the failures from the above
Jason Vas Dias added the comment:
no, 'make test V=1' still fails with 'run in verbose mode for details' .
does it mean 'make test verbose=1' ? 'make test mode=verbose' ?
--
___
Python tra
Jason Vas Dias added the comment:
$ ls -l /usr/lib64/libffi*
-rwxr-xr-x 1 root root 36839 May 25 2008 /usr/lib64/libffi-2.00-beta.so
-rw-r--r-- 1 root root 193480 Apr 29 13:22 /usr/lib64/libffi.a
-rwxr-xr-x 1 root root904 Apr 29 13:22 /usr/lib64/libffi.la
lrwxrwxrwx 1 root root 15 Apr
Jason Vas Dias added the comment:
suspect cause #1 - bad system libffi ? I just built it, but :
$ ls -l /usr/lib64/libffi*
-rwxr-xr-x 1 root root 36839 May 25 2008 /usr/lib64/libffi-2.00-beta.so
-rw-r--r-- 1 root root 201320 Apr 8 03:46 /usr/lib64/libffi.a
lrwxrwxrwx 1 root root 15 Apr
Jason Vas Dias added the comment:
my expat was just built a few weeks ago from expat-2.0.1.tar.gz:
$ ls -l /usr/lib64/libexpat*
-rw-r--r-- 1 root root 577052 Apr 8 21:52 /usr/lib64/libexpat.a
lrwxrwxrwx 1 root root 17 Apr 8 21:52 /usr/lib64/libexpat.so ->
libexpat.so.1.5.2
lrwxrwxrw
Changes by Jason Vas Dias :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue11954>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Jason Vas Dias :
--
components: +Build
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue11954>
___
___
Python-bugs-list mailin
New submission from Jason Vas Dias :
I do :
$ hg clone http://hg.python.org/cpython
( my existing Python-2.7, following upgrade to glibc-2.13, started
producing erroneous results - see gnome.org glib bug :
https://bugzilla.gnome.org/show_bug.cgi?id=648863
So I tried downloading and
Jason Vas Dias added the comment:
OK, the test failures reported for this bug now succeed with Python-3.3
from latest HG head .
But Python-3.3 now has its own new test failures :
[149/354] test_import
Jason Vas Dias added the comment:
Furthermore, look at your configure script output :
checking for int32_t... yes
checking for int64_t... yes
Jason Vas Dias added the comment:
In case you don't believe me, believe a "C" compiler :
$ echo -e '#include \nint main(){ printf("%u
%u\\n",sizeof(int),sizeof(void*));}' > si.c
$ gcc -o si si.c
$ ./si
4 8
Any code that assumes that "sizeof(int) ==
Jason Vas Dias added the comment:
Aha ! Yes, I see, it is the extra '.' - this test now works :
$ cat test.py
import os
import sys
import re
pat = r'''d. # It is a directory.
[+.@]?
\s+\d+ # It has some number of links.
Jason Vas Dias added the comment:
RE: msg134737 :
> indeed this test bug was only recently (April 4th!) fixed.
Please can you let me know how to get the patch / source / that fixes this ?
The bug # of the original bug ? Should I be building from GIT ? Which GIT tag ?
I'll try t
Jason Vas Dias added the comment:
When I see messages like this in the "make test" log it makes me
want to remove python and all python using software from my system :
test_dl
test test_dl crashed -- : module dl requires
sizeof(int) == sizeof(long) == sizeof(char*)
NO, GEE, TH
Jason Vas Dias added the comment:
I imagine lots of other python REs fail if this one is failing ? :
$ cat test.py
import os
import sys
import re
pat = r'''d. # It is a directory.
\+? # It may have ACLs.
\s+\d+ # It has some
Jason Vas Dias added the comment:
Oops, Paul is right here - I asked bug-coreut...@gnu.org, and Paul
responds:
Re: bug#8578: 8.12 and 8.10 'ls -dl' appends ' ' (0x20: space) to file output
lines
From: Paul Eggert (UCLA Computer Science Department)
To: jason.vas.d.
Jason Vas Dias added the comment:
$ ls -dl /. | od -x
000 7264 7877 2d72 7278 782d 202e 3532 7220
020 6f6f 2074 6f72 746f 3420 3930 2036 7041
040 2072 3032 3120 3a35 3832 2f20 0a2e
056
[ root@jvdspc:/tmp 19:15:01 1730:1223 ]
$ ls --version
ls (GNU coreutils) 8.12
Either GNU
Jason Vas Dias added the comment:
Wow, GNU have respun two major releases of coreutils since I built
coreutils-2.10 two weeks ago !
Now moving to latest version of coreutils : 8.12 and retesting .
--
___
Python tracker
<http://bugs.python.
Changes by Jason Vas Dias :
--
keywords: +patch
Added file: http://bugs.python.org/file21827/bug_11946.patch
___
Python tracker
<http://bugs.python.org/issue11
Jason Vas Dias added the comment:
Not sure if relevant, but ls is appending a ' ' (0x20 == space) after
the filename :
$ ls -ld -d /. | od -x
000 7264 7877 2d72 7278 782d 202e 3532 7220
020 6f6f 2074 6f72 746f 3420 3930 2036 7041
040 2072 3032 3120 3a35 3832 2f20 0a2e
00
Jason Vas Dias added the comment:
oops, over-eager bash again -
I've certainly had one too many bash s today :-)
Here's the patch against 2.7.1's test_commands.py, not 2.7's :
[ root@jvdspc:/mnt/sda3/Python-2.7 18:04:15 1687:1180 ]
$ diff -U0 /usr/src/Python-2.7.1/Lib/t
Jason Vas Dias added the comment:
Aha ! Fixed ! : patch :
[ root@jvdspc:/mnt/sda3/Python-2.7 18:02:22 1685:1178 ]
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python
/tmp/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests
Jason Vas Dias added the comment:
Newly built python 2.7.1 commands.getstatus succeeds :
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python
Python 2.7.1 (r271:86832, Apr 28 2011, 15:53:47)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credi
Jason Vas Dias added the comment:
new strace 4.6 of newly built python 2.7.1 failing test_commands.py
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 strace -s8192 -f
-e trace=execve ./python /usr/src/Python-2.7.1/Lib/test/test_commands.py
execve("./python", ["./
Jason Vas Dias added the comment:
$ python
Python 2.7 (r27:82500, Jul 4 2010, 23:30:10)
[GCC 4.4.2 20090927 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import re
>&
Jason Vas Dias added the comment:
Hmm.. investigating that "syscall_293..." stuff - I did
$ cd /usr/src/linux; make headers_install
and then built glibc-2.13 with the new header OK, but
strace is rather old . I'll rebuild strace ...
--
___
Jason Vas Dias added the comment:
Seeing the source , I see some complicated RE - should this test
maybe be better off in the RE testing module ?
I'd have used a simple RE like '^.*(\/.*)$' .
Might my newly built & installed pcre-8.02 be a suspect here ?
Here is an stra
Jason Vas Dias added the comment:
$ ls -ld /.
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
(oops, forgot the '.' suffix before)
--
___
Python tracker
<http://bugs.python.o
Jason Vas Dias added the comment:
$ ldd /usr/bin/python
linux-vdso.so.1 => (0x7fff1edff000)
libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
(0x7f16aa8c)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x7f16aa6a3000)
libdl.so.
Jason Vas Dias added the comment:
$ uname -a
Linux jvdspc 2.6.38.2-jvd #1 SMP Sun Apr 3 00:55:29 BST 2011 x86_64 GNU/Linux
$ ls -ld /
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /
$ ls --version
ls (GNU coreutils) 8.10
...
$ eval {gcc,g++,cpp,ld,as,ar,ranlib,objdump,objcopy,make,bash,ldconfig
Jason Vas Dias added the comment:
Oops, bash completion was a bit over-eager, and I inadvertently
built /usr/src/Python-2.7 instead of /usr/src/Python-2.7.1 .
Nevertheless, when I finally do build Python-2.7.1, I get the same
error :
test_commands
New submission from Jason Vas Dias :
After building from source in Python-2.7.1.tar.bz2 ,
I get this 'make test' failure :
test_commands
test test_commands failed -- Traceback (most recent call last):
File "/usr/src/Python-2.7/Lib/test/test_commands.py", line 61
65 matches
Mail list logo
