[issue11946] 2.7.1 'test_commands' build test fails

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/crti.o *endfiles: + /lib3

[issue11946] 2.7.1 'test_commands' build test fails

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 your gcc

[issue11946] 2.7.1 'test_commands' build test fails

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 seem sensible to you?? Well, it d

[issue11946] 2.7.1 'test_commands' build test fails

Alex Leach added the comment: Hey Jason, Thanks for replying so quickly, and on a bank holiday! :) This has completely diverged from the original bug, but whatever.. Thanks for the C wrapper too! It's not appropriate for my build environment, and I know no C, having only got so far as writing

[issue11946] 2.7.1 'test_commands' build test fails

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 */]) = 0 [ Process PID=3559 runs in 32 bit mode.

[issue11946] 2.7.1 'test_commands' build test fails

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 awesome ... I think Python is

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: The test_commands fix will be in 2.7.2. 2.7.1 was released well before the fix was made. -- ___ Python tracker ___ _

[issue11946] 2.7.1 'test_commands' build test fails

Alex Leach added the comment: I got the same test_commands fail when building a Python2.7.1 which I downloaded yesterday; it's on an FC13 x86_64 server. I've built python2.7 before using a similar machine, but it's not picking up my external libraries on a Sun Grid Engine, leaving me with impo

[issue11946] 2.7.1 'test_commands' build test fails

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/bin/python${VERSION}.bin" ;; esac

[issue11946] 2.7.1 'test_commands' build test fails

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=`uname -

[issue11946] 2.7.1 'test_commands' build test fails

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=`u

[issue11946] 2.7.1 'test_commands' build test fails

Georg Brandl added the comment: I'm going to state this one again: missing modules are *NOT* a build failure. It is pretty common to not install a certain library (or headers for them), if you don't need/want the Python module using it. (And editing Modules/Setup to add modules that setup.py

[issue11946] 2.7.1 'test_commands' build test fails

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 can do "my standar

[issue11946] 2.7.1 'test_commands' build test fails

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", "3-way", "intel" or "all

[issue11946] 2.7.1 'test_commands' build test fails

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/lib64/python-

[issue11946] 2.7.1 'test_commands' build test fails

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 ). This time I don't

[issue11946] 2.7.1 'test_commands' build test fails

Georg Brandl added the comment: Not sure why you would prefer an unstable, unreleased hg trunk version to a stable, released one. And as you've seen, Python 2 and Python 3 are quite different things. As for dl failing on build, you've already stated that it does *not* build, together with bs

[issue11946] 2.7.1 'test_commands' build test fails

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 python;' (/usr

[issue11946] 2.7.1 'test_commands' build test fails

Georg Brandl added the comment: Jason, that the dl module requires sizeof(int) == sizeof(char *) does not mean that it (or we) thinks this to be true on every platform. Rather, the module is written in a way that requires this equality, and rather than crashing it does this check beforehand.

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: Sorry, didn't see that you'd figured it out in the midst of your other comments not relevant to this bug. If the re were simpler it wouldn't actually be *testing* the function under test, and so would be a useless test. (It would show that the function pro

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: No, if you take a look at tip, the problem is that bit of re is not covering all cases, and should look like this: [.+@]? # It may have special attributes. I assumed the "." was selinux, but I don't actually know, as I don't see them on my system (I

[issue11946] 2.7.1 'test_commands' build test fails

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

[issue11946] 2.7.1 'test_commands' build test fails

Jason Vas Dias added the comment: Furthermore, look at your configure script output : checking for int32_t... yes checking for int64_t... yes

[issue11946] 2.7.1 'test_commands' build test fails

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) == sizeof(char*)" on an x86_64 is broken, and a

[issue11946] 2.7.1 'test_commands' build test fails

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. [^/]*# Skip user,

[issue11946] 2.7.1 'test_commands' build test fails

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 that next ...

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: Oh, drat. We could have figured this out much sooner if I'd been paying closer attention. I was testing based on current 2.7 tip instead of 2.7.1, and indeed this test bug was only recently (April 4th!) fixed. And the issue is indeed selinux; the fix was

[issue11946] 2.7.1 'test_commands' build test fails

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, THAT'S RIGHT !

[issue11946] 2.7.1 'test_commands' build test fails

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 number of links.

[issue11946] 2.7.1 'test_commands' build test fails

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...@gmail.com CC: 8...@

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: By the way, I wouldn't expect most programs to ever notice that trailing space parsing -l output, but if it also attaches the trailing space in regular ls output, *that* I would expect more programs would trip over. -- __

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: I would say that coreutils is wrong to be appending a space. If a program were to parse the output of ls, it would reasonably expect the filename to be rendered exactly as it appears in the directory. That is, a program should treat a trailing space as *pa

[issue11946] 2.7.1 'test_commands' build test fails

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 cor

[issue11946] 2.7.1 'test_commands' build test fails

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

[issue11946] 2.7.1 'test_commands' build test fails

Changes by Jason Vas Dias : -- keywords: +patch Added file: http://bugs.python.org/file21827/bug_11946.patch ___ Python tracker ___ __

[issue11946] 2.7.1 'test_commands' build test fails

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 056 See t

[issue11946] 2.7.1 'test_commands' build test fails

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/test/test_commands.py /

[issue11946] 2.7.1 'test_commands' build test fails

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) ...

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: You are running selinux, right? Have you checked for things in the log that might indicate selinux is blocking the ls call for some reason? -- ___ Python tracker __

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: Hmm. This is very odd. The output from getstatus is the same as your ls output, and that output passes the re. Python has its own regular expression implementation, so your pcre version shouldn't have anything to do with it. That complicated re, by the wa

[issue11946] 2.7.1 'test_commands' build test fails

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", "credits" or "license" for more informa

[issue11946] 2.7.1 'test_commands' build test fails

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", ["./python", "/usr/sr

[issue11946] 2.7.1 'test_commands' build test fails

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 >>> import sys >>> import commands >>> print commands.getstatus(

[issue11946] 2.7.1 'test_commands' build test fails

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 ... -- ___ Python

[issue11946] 2.7.1 'test_commands' build test fails

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 strace of the installed pyt

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: The re matches for me if I call it manually with your ls -ld output. What output do you get if you do a 'print commands.getstatus("/.")' using your build of the python interpreter? By the way, this is a deprecated function under test here, so I'm setting thi

[issue11946] 2.7.1 'test_commands' build test fails

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 ___ _

[issue11946] 2.7.1 'test_commands' build test fails

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.2 => /usr/lib64

[issue11946] 2.7.1 'test_commands' build test fails

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}'

[issue11946] 2.7.1 'test_commands' build test fails

R. David Murray added the comment: We don't ship unless all tests pass on all of our test platforms (and we have quite a few). If you look at that test it says the regex "should match 'ls -ld /.' on any posix system, however perversely configured". Perhaps your system has managed a new bran

[issue11946] 2.7.1 'test_commands' build test fails

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

[issue11946] 2.7.1 'test_commands' build test fails

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, in test_getstatus self.a