[issue11946] 2.7.1 'test_commands' build test fails
Alex Leach beamesle...@gmail.com 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 import errors. Probably problems with the environment ($PYTHONHOME $PYTHONPATH), but playing with these don't fix my batch jobs, so I've decided to build a cross-compiled version, which I've done on a Mac Pro before, but not a linux server, where --with-universal-archs doesn't work. I'm not a guru with using CFLAGS args during compilation, so I think I'll end up compiling it twice (long, I need this to work yesterday), using Jason's configure arguments (that -m32 is the ticket), and taking Jason's wrapper script, modifying it for my home dir. Thanks for posting that Jason!! I'd already started implementing something similar in my batch script, but yours looks much more thorough. Whilst here, I wanted to advocate python a bit. I think it's awesome, and an article that articulates it's awesomeness fairly amusingly, can be found here:- http://www.linuxjournal.com/article/3882 Still, I'm also disappointed with these build problems. I left `make test` running overnight and it had hung, using 100% of a CPU the whole night. I'm not even half-way to getting python compiled... :( Will probably also need to recompile ATLAS as well as numpy / biopython for both archs - no quick or easy feat. -- nosy: +Alex.Leach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 awesome too - I've been programming with it for nearly eight years now - but I HATE the modern propensity for replacing perfectly OK C programs and shell scripts with Python , or any other interpreter, Just for the sake of it, - let's be clear what an interpreter or compiler's job is : it is to present the correct machine code to the computer for execution to perform a certain well defined task . So I don't think an interpreter script is automatically, by definition, preferable to a compiled executable. And I don't like significant white-space and PERL will always be my preferred script interpreter, sorry Python, that's just the way it is . I'm appending the C source python wrapper program that I use after this. -- Added file: http://bugs.python.org/file22196/python.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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. ] Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12) [GCC 4.6.0] on linux2 Type help, copyright, credits or license for more information. $ strace -s8192 -e trace=execve /usr/bin/python2.7 execve(/usr/bin/python2.7, [/usr/bin/python2.7], [/* 65 vars */]) = 0 execve(/usr/bin//32/python2.7, [/usr/bin//32/python2.7], [/* 66 vars */]) = 0 [ Process PID=3571 runs in 32 bit mode. ] Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12) [GCC 4.6.0] on linux2 Type help, copyright, credits or license for more information. This is necessary because the 32-bit /usr/bin/32/python*'s PYTHONHOME is /usr/lib32/python2.7 , where 32-bit shared library python modules are installed under lib-dynload/, while the native 64-bit's /usr/bin/python2.7's PYTHONHOME is /usr/lib64/python2.7 which has 64-bit libraries in lib-dynload . The 32-bit python uses /etc/32/ as its $SYSCONFDIR . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Alex Leach beamesle...@gmail.com 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 a hello world program with it, so I'll probably stick with my bash wrapper script for now. Currently re-compiling python2.7.1 to support i686 machines. The first build wasn't allowing me to compile numpy with the supplied atlas libraries, failing to pick up the extension .so.3 / .so.3.0 which I think has something to do with position independent code, so 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?? The relevant part of my bash wrapper script (for sun grid engine) is then something like:- #!/bin/bash if [[ `uname -m` = x86_64 ]] ; then export PYTHONHOME=$HOME/ else echo arch = `uname -m` export PYTHONHOME=$HOME/32 fi -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 depends on the output of these commands on your system :
$ gcc -print-search-dirs | grep '^libraries'
libraries:
=/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/
$ gcc -print-multi-os-directory
../lib64
Your C compiler should be appending an option such as :
'--dynamic-linker=/lib32/ld-linux.so.2 -rpath /usr/lib32:/lib32'
to it's ld(1) command line - if you have C compilation problems, look
at the output of adding '--verbose' to the $CFLAGS you
gave and looking at what options are used by gcc's 'collect' phase:
$ gcc -o /tmp/t ~jason/t.c --verbose 21 | tail -n 2
COLLECT_GCC_OPTIONS='-o' '/tmp/t' '-v' '-mtune=k8' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /tmp/t
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crt1.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtbegin.o
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. /tmp/ccoSip93.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtend.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o
$ gcc -m32 -o /tmp/t ~jason/t.c --verbose 21 | tail -n 2
COLLECT_GCC_OPTIONS='-m32' '-o' '/tmp/t' '-v' '-mtune=i686' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib32/ld-linux.so.2 -o /tmp/t
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crt1.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crti.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/crtbegin.o
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32 -L/lib/../lib32
-L/usr/lib/../lib32 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. /tmp/ccZzwAuw.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/crtend.o
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crtn.o
'~jason/t.c' is just :
$ echo -e '#include stdio.h\nint main(){ printf(hello world!\n);}'
~jason/t.c
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, your
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 is compiled with '--enable-multilib' and '--enable-targets=all', as mine is , and that you have applied something like this patch to gcc's gcc/config/i386/linux*.h files: $ gendiff gcc/config '~' diff -up gcc/config/i386/linux.h~ gcc/config/i386/linux.h --- gcc/config/i386/linux.h~2011-01-14 18:45:06.0 + +++ gcc/config/i386/linux.h 2011-04-05 22:17:10.0 +0100 @@ -92,7 +92,7 @@ along with GCC; see the file COPYING3. /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */ #define LINK_EMULATION elf_i386 -#define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2 +#define GLIBC_DYNAMIC_LINKER /lib32/ld-linux.so.2 #undef ASM_SPEC #define ASM_SPEC \ diff -up gcc/config/i386/linux64.h~ gcc/config/i386/linux64.h --- gcc/config/i386/linux64.h~ 2011-03-02 22:35:36.0 + +++ gcc/config/i386/linux64.h 2011-04-05 22:17:33.0 +0100 @@ -62,7 +62,7 @@ see the files COPYING3 and COPYING.RUNTI When the -shared link option is used a final link is not being done. */ -#define GLIBC_DYNAMIC_LINKER32 /lib/ld-linux.so.2 +#define GLIBC_DYNAMIC_LINKER32 /lib32/ld-linux.so.2 #define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2 #if TARGET_64BIT_DEFAULT -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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:
+ /lib32/crtn.o
*link:
+ -dynamic-linker
/usr/local/lib%{!m32:64}%{m32:32}/ld-linux-%{!m32:x86_64}%{m32:i386}.so.2
-L/usr/local/lib/gcc-lib/%{!m32:x86_64-redhat-linux}%{m32:i386-redhat-linux}/4/%{m32:32}
-L/usr/local/lib/%{!m32:64}%{m32:32}
-R/usr/local/lib/gcc/%{!m32:x86_64-redhat-linux}%{m32:i386-redhat-linux}/4
-R/usr/local/lib%{m32:32}%{!m32:64} -R/usr/local/lib
*cpp:
+ -isystem /usr/local/include
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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/bin/python2.7 executable still exists) all the software
I now attempt to build insists on using python2 , which is built
against an old glibc and has started giving anomalous results
after upgrade to newer glibc - see :
https://bugzilla.gnome.org/show_bug.cgi?id=648863
where I found that my python-2.7 was failing to
'from . import config'
whereas the FC-14 python 2.7 got past this .
So I still need to find a way of building python 2.7.1 to replace
my broken old system python2 .
When I tried this, doing :
$ /usr/src/Python-2.7.1/configure --prefix=/usr --libdir=/usr/lib64
--enable-shared CXX=${CXX} CXXFLAGS=$CXXFLAGS
(I only added the CXX= args because configure complained that while
I did have $CXX set to /usr/bin/g++ , c++ would be used )
the build failed complaining that the 'bsddb185 dl gdbm' modules
could not be built; I had to change the $CPPFLAGS to contain
'-I/usr/include/db4' and --libs to contain '-ldb-4.5 -lgdbm' and
comment out and modify the lines in Module/Setup :
#dl dlmodule.c
...
#gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib -lgdbm
...
#_bsddb _bsddb.c -I$(DBINC) -L$(DBLIB) -ldb-$(DBLIBVER)
and then the build succeeded , but with these errors from dlmodule :
test_dl
test test_dl crashed -- type 'exceptions.SystemError': module dl requires
sizeof(int) == sizeof(long) == sizeof(char*)
My point is, if this test_dl works only in 32-bit mode, it should
have failed during its build, not during test !
If it is meant to be 32-bit only, say something like :
#if __LONG_MAX__ 0x
#error dlmodule only works in 32-bit mode.
#endif
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Georg Brandl ge...@python.org 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 bsddb185 and gdbm (for which the library headers are missing). setup.py does exactly that test for 64-bit platforms. Then you activate it explicitly, and complain that it does build... And lastly, all these things are *not* a build failure of Python: missing modules just means that, well, these modules won't be there. And failing tests just means that there *may* be a problem when using the respective module -- but for platform-dependent modules it could just as well mean that your system is configured in a special way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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__ 0xU /* cpp -dM builtin : __LONG_MAX__ */ #error dlmodule only works in 32-bit mode. #endif -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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-$V
32-bit installing /usr/lib/python-$V as /usr/lib32/python-$V
2. Replace /usr/bin/python with a shell script or program which does
something like (in shell):
#!/bin/sh
if `uname -m` = i686 ; then # I'm in a 'setarch i686' env
exec /usr/bin/32/python${0#python} $*
else
exec /usr/bin/python${0#python} $*
fi
Any thoughts about / advice on doing something like this ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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) ie: --with-univeral-archs='64-bit 32-bit' ?? The fact that the python --configure ignores my '--libdir=/usr/lib64' setting and installs files under /usr/lib regardless suggest this would NOT work as I expect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 python-2.7/32/pyconfig.h
#else
#include python-2.7/64/pyconfig.h
#endif
and that's it ! After building i686-Python-2.7.1, I can do
my standard python post-install script :
$ ABI=64; V=2.7
$ DESTDIR=`pwd`/inst make install
$ cd inst/usr
$ mv lib${ABI}/python${V}/* lib/python$V
$ rmdir lib${ABI}/python-${V}
$ mv lib/python-${V} lib$ABI
$ rmdir lib
And then:
$ cd inst/usr/include/python$V
$ for f in *; do cmp $f /usr/include/python2.7/$f; done
pyconfig.h /usr/include/python2.7/pyconfig.h differ: char 11124, line 393
$ $ diff -U0 pyconfig.h /usr/include/python2.7/pyconfig.h
--- pyconfig.h 2011-04-30 13:34:21.0 +0100
+++ /usr/include/python2.7/pyconfig.h 2011-04-30 12:34:23.0 +0100
@@ -393 +393 @@
-#define HAVE_LARGEFILE_SUPPORT 1
+/* #undef HAVE_LARGEFILE_SUPPORT */
@@ -989 +989 @@
-#define SIZEOF_LONG 4
+#define SIZEOF_LONG 8
@@ -992 +992 @@
-#define SIZEOF_LONG_DOUBLE 12
+#define SIZEOF_LONG_DOUBLE 16
@@ -1004 +1004 @@
-#define SIZEOF_PTHREAD_T 4
+#define SIZEOF_PTHREAD_T 8
@@ -1010 +1010 @@
-#define SIZEOF_SIZE_T 4
+#define SIZEOF_SIZE_T 8
@@ -1013 +1013 @@
-#define SIZEOF_TIME_T 4
+#define SIZEOF_TIME_T 8
@@ -1016 +1016 @@
-#define SIZEOF_UINTPTR_T 4
+#define SIZEOF_UINTPTR_T 8
@@ -1019 +1019 @@
-#define SIZEOF_VOID_P 4
+#define SIZEOF_VOID_P 8
@@ -1069 +1069 @@
-/* #undef VA_LIST_IS_ARRAY */
+#define VA_LIST_IS_ARRAY 1
@@ -1121 +1121 @@
-#define X87_DOUBLE_ROUNDING 1
+/* #undef X87_DOUBLE_ROUNDING */
so this is the ONLY file that needs to be wrapped to work in a
multi-arch environment.
BTW, I know you can't use runtime expressions such as
'sizeof(char*)'
in cpp macros, but you CAN get much the same effect by
using cpp 'builtin macros' :
e.g. you could write :
#if __LONG_MAX__ 0xU
#define SIZEOF_LONG 8 /*works until you want to support 128 / 256 bit */
#else
#define SIZEOF_LONG 4 /* guess you don't want to support 16 or 8 bit ?*/
#endif
and then pyconfig.h would not need to be wrapped .
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Georg Brandl ge...@python.org 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 detects as not buildable won't make them buildable in 99% of cases.) As for the dl module, the existing check in setup.py is just fine, especially since dl is deprecated and not present anymore in 3.x. There will always be ways to shoot yourself in the foot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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=`uname -m`
case $ARCH in
i686)
exec /usr/bin/32/${ME} $*
;;
*)
exec /usr/bin/python${VERSION} $*
;;
esac
So now, in a native 64-bit env :
$ python
Python 2.7.1 (r271:86832, Apr 30 2011, 11:55:52)
[GCC 4.6.0] on linux2
Type help, copyright, credits or license for more information.
^D
$ setarch i686
$ python
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type help, copyright, credits or license for more information.
See the build times, they are different executables !
And final, complete working /usr/include/python2.7/pyconfig.h :
$ echo '#include python2.7/pyconfig.h' pyc.c
$ cpp pyc.c
$ cpp pyc.c
# 1 pyc.c
# 1 built-in
# 1 command-line
# 1 pyc.c
# 1 /usr/include/python2.7/pyconfig.h 1 3 4
# 1 /usr/include/python2.7/64/pyconfig.h 1 3 4
# 5 /usr/include/python2.7/pyconfig.h 2 3 4
# 1 pyc.c 2
$ cpp -m32 pyc.c
# 1 pyc.c
# 1 built-in
# 1 command-line
# 1 pyc.c
# 1 /usr/include/python2.7/pyconfig.h 1 3 4
# 1 /usr/include/python2.7/32/pyconfig.h 1 3 4
# 3 /usr/include/python2.7/pyconfig.h 2 3 4
# 1 pyc.c 2
$ cat /usr/include/python2.7/pyconfig.h
#ifdef __i386__
#include python2.7/32/pyconfig.h
#else
#include python2.7/64/pyconfig.h
#endif
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 -m`
CMD=''
case $ARCH in
i686)
CMD=/usr/bin/32/${ME}
;;
*)
CMD=/usr/bin/python${VERSION}.bin
;;
esac
for((a=1;a=$#;a++));do CMD=${CMD} '$(eval 'echo -n $'$a'')' ;done
eval exec $CMD
I had to move the /usr/bin/python${VERSION} executables to
/usr/bin/python${VERSION}.bin , and replace them with copies
of this python script (which runs whichever version it is named by).
And I can do:
$ python -c 'import os
import sys
import commands
print commands.getstatus(ls -ld /.)
'
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
under both the native x86_64 and a 'setarch i686' environment with
the same results.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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
for((a=1;a=$#;a++));do CMD=${CMD} '$(eval 'echo -e $'$a'' | sed
's/[''']/'/g')' ;done
eval exec $CMD
now handles:
$ ./python -c 'import os
import sys
import commands
print commands.getstatus('''/.''')
'
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 ... And the issue is indeed selinux; the fix was to the regex to take into account the selinux extra attributes. selinux is disabled on my system, there were no SELinux attributes in the string emitted by 'ls -dl' - and the python executable does not link to libselinux - so you're saying that, in this code : pat = r'''d. # It is a directory. \+? # It may have ACLs. '\+?' is incorrectly requiring '+' ? Surely this is a bug in the regexp code ? Nope, I don't think it has anything to do with SELinux attributes - when I remove the '\+?', the RE still fails : $ 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, group, size, and date. /\. # and end with the name of the file. ''' str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.' if re.match(pat, str, re.VERBOSE) : print MATCHED\n else : print DID NOT MATCH $ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py DID NOT MATCH RE: As for the other issue, please open a new ticket. (The pseudo-code, by the way, is saying that all three sizes must be the same.) This really frightens me - do you really believe that all three sizes must be the same on an x86_64 ? : test_dl test test_dl crashed -- type 'exceptions.SystemError': module dl requires sizeof(int) == sizeof(long) == sizeof(char*) That your dynamic linking module should give the impression in its test script that it thinks 'sizeof(int)' (==4) should be equal to 'sizeof(char*)' (==8) is rather disconcerting to say the least - and terrifying if it actually acts on this fundamental misconception in its code - the fact that it crashed suggests maybe this is the case. I'll see what happens with this test for the new code build and raise another issue if not fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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, group, size, and date. /\. # and end with the name of the file. ''' str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.' if re.match(pat, str, re.VERBOSE) : print MATCHED\n else : print DID NOT MATCH [ root@jvdspc:/mnt/sda3/Python-2.7 11:19:30 1758:1251 ] $ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py MATCHED I still think that RE belongs in a 'test_re' script, not in the 'test_commands' script - this whole series of issues could have been avoided if the programmer had refrained from showing off their RE prowess for no purpose here and just used a simple RE like '^.*/\.$' . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com added the comment:
In case you don't believe me, believe a C compiler :
$ echo -e '#include stdio.h\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 any test that emits messages to this
effect is profoundly disconcerting . I wish I didn't have to
support python on my system.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com added the comment: Furthermore, look at your configure script output : checking for int32_t... yes checking for int64_t... yes checking for ssize_t... yes checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking size of fpos_t... 16 checking size of size_t... 8 checking size of pid_t... 4 checking for long long support... yes checking size of long long... 8 So why does your test_dl script say sizeof(int)==sizeof(char*) ?? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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
test test_import failed -- Traceback (most recent call last):
File /usr/src/cpython/Lib/test/test_import.py, line 545, in
test_unwritable_directory
'__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag
AssertionError: True is not false
Hmm, don't want a python that can't do 'import' .
So my choices are, in order to get a working modern python release :
o fix the broken dynamic loader in Python-2.7
o fix the broken import mechanism in Python-3.3
Thanks !
BTW, this error occurs because I don't have RPM :
[ 93/354] test_distutils
error: error creating temporary file ${prefix}/var/tmp/rpm-tmp.amzIxR: No such
file or directory
error: Unable to open temp file.
error: error creating temporary file ${prefix}/var/tmp/rpm-tmp.nwKS2z: No such
file or directory
error: Unable to open temp file.
test test_distutils failed -- multiple errors occurred; run in verbose mode for
details
this is because I don't have RPM (or maybe an old broken RPM inst) -
I suggest this test should test for the existence and usability
of rpm before using rpm - and should skip itself if rpm not usable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 don't use selinux or, apparently, any other special attributes). So, the reason the re is failing is the trailing '.' in the first token in your ls -ld result, whatever that comes from. The fixed test re allows for the '.'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 produced output, but not that the output was from the ls -ld command) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Georg Brandl ge...@python.org 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. As you may have noticed, the dl module is deprecated anyway in favor of ctypes, and removed in Python 3.x. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
New submission from Jason Vas Dias jason.vas.d...@gmail.com: 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.assertTrue(re.match(pat, commands.getstatus(/.),re.VERBOSE)) AssertionError: None is not True I don't get this error when building from Python-2.7.tar.bz2 -- components: Tests messages: 134674 nosy: Jason.Vas.Dias priority: normal severity: normal status: open title: 2.7.1 'test_commands' build test fails versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com added the comment: Oops, bash TAB 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 test test_commands failed -- Traceback (most recent call last): File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 61, in test_getstatus self.assertTrue(re.match(pat, commands.getstatus(/.), re.VERBOSE)) AssertionError: None is not True I guess if python-2.7 cannot run command I'd know about it, and it has the same bug. I guess you ship a broken 'test_commands' test script for Python-2.7 AND Python-2.7.1 . This does not increase my already meager confidence in Python's robustness and reliability. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 brand of perversity :) Seriously, though, it looks like the test is broken in the face of some edge case present on your system and not on any of our test machines. Can you provide the output of 'ls -ld /.' from your system please? And also your OS and filesystem types and versions. -- nosy: +r.david.murray type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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}'
--version;' | egrep '[(]G|bash'
gcc (GCC) 4.6.0
g++ (GCC) 4.6.0
cpp (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21.51.20110407
GNU assembler (GNU Binutils) 2.21.51.20110407
GNU ar (GNU Binutils) 2.21.51.20110407
GNU ranlib (GNU Binutils) 2.21.51.20110407
GNU objdump (GNU Binutils) 2.21.51.20110407
GNU objcopy (GNU Binutils) 2.21.51.20110407
GNU bash, version 4.2.8(2)-release (x86_64-pc-linux-gnu)
ldconfig (GNU libc) 2.13
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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/libdl.so.2 (0x7f16aa49f000) libutil.so.1 = /lib64/libutil.so.1 (0x7f16aa29c000) libm.so.6 = /lib64/libm.so.6 (0x7f16aa01a000) libc.so.6 = /lib64/libc.so.6 (0x7f16a9c92000) /lib64/ld-linux-x86-64.so.2 (0x7f16aac9) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com added the comment: $ ls -ld /. drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /. (oops, forgot the '.' suffix before) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 this bug to low priority. But I'm certainly curious as to what the problem is. -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 python 2.7 (not 2.7.1!)
failing with test_commands.py :
$ strace -s8192 -f -e trace=execve python
/usr/src/Python-2.7.1/Lib/test/test_commands.py
execve(/usr/bin/python, [python,
/usr/src/Python-2.7.1/Lib/test/test_commands.py], [/* 23 vars */]) = 0
test_getoutput (__main__.CommandTests) ... syscall_293(0x7fffa0d6a400, 0x8,
0x7f4029a834dd, 0x7fffa0d6a200, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
Process 30803 attached
[pid 30803] execve(/bin/sh, [sh, -c, { echo xyzzy; } 21], [/* 23 vars
*/]) = 0
Process 30803 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
syscall_293(0x7fffa0d6a550, 0x8, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) =
0
Process 30804 attached
[pid 30804] execve(/bin/sh, [sh, -c, { echo xyzzy; } 21], [/* 23 vars
*/]) = 0
Process 30804 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
syscall_293(0x7fffa0d6a550, 0x8, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) =
0
Process 30805 attached
[pid 30805] execve(/bin/sh, [sh, -c, { cat /tmp/tmpZ2sqbO/foo; } 21],
[/* 23 vars */]) = 0
Process 30806 attached
[pid 30806] execve(/bin/cat, [cat, /tmp/tmpZ2sqbO/foo], [/* 21 vars */])
= 0
Process 30805 suspended
Process 30805 resumed
Process 30806 detached
[pid 30805] --- SIGCHLD (Child exited) @ 0 (0) ---
Process 30805 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
ok
test_getstatus (__main__.CommandTests) ... syscall_293(0x7fffa0d6a2b0, 0x8,
0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
Process 30807 attached
[pid 30807] execve(/bin/sh, [sh, -c, { ls -ld \'/.\'; } 21], [/* 23
vars */]) = 0
Process 30808 attached
Process 30807 suspended
[pid 30808] execve(/bin/ls, [ls, -ld, /.], [/* 21 vars */]) = 0
Process 30807 resumed
Process 30808 detached
[pid 30807] --- SIGCHLD (Child exited) @ 0 (0) ---
Process 30807 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
FAIL
==
FAIL: test_getstatus (__main__.CommandTests)
--
Traceback (most recent call last):
File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 61, in
test_getstatus
self.assertTrue(re.match(pat, commands.getstatus(/.), re.VERBOSE))
AssertionError: None is not True
--
Ran 2 tests in 0.202s
FAILED (failures=1)
Traceback (most recent call last):
File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 70, in module
test_main()
File
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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(/.) drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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/src/Python-2.7.1/Lib/test/test_commands.py], [/* 25 vars */]) = 0
test_getoutput (__main__.CommandTests) ... Process 1327 attached
[pid 1327] execve(/bin/sh, [sh, -c, { echo xyzzy; } 21], [/* 25 vars
*/]) = 0
Process 1327 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1327, si_status=0,
si_utime=0, si_stime=1} (Child exited) ---
Process 1328 attached
[pid 1328] execve(/bin/sh, [sh, -c, { echo xyzzy; } 21], [/* 25 vars
*/]) = 0
Process 1328 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1328, si_status=0,
si_utime=0, si_stime=1} (Child exited) ---
Process 1329 attached
[pid 1329] execve(/bin/sh, [sh, -c, { cat /tmp/tmp2EkRJK/foo; } 21],
[/* 25 vars */]) = 0
Process 1330 attached
Process 1329 suspended
[pid 1330] execve(/bin/cat, [cat, /tmp/tmp2EkRJK/foo], [/* 23 vars */])
= 0
Process 1329 resumed
Process 1330 detached
[pid 1329] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1330,
si_status=1, si_utime=0, si_stime=0} (Child exited) ---
Process 1329 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1329, si_status=1,
si_utime=0, si_stime=1} (Child exited) ---
ok
test_getstatus (__main__.CommandTests) ... Process 1338 attached
[pid 1338] execve(/bin/sh, [sh, -c, { ls -ld '/.'; } 21], [/* 25
vars */]) = 0
Process 1339 attached
Process 1338 suspended
[pid 1339] execve(/bin/ls, [ls, -ld, /.], [/* 23 vars */]) = 0
Process 1338 resumed
Process 1339 detached
[pid 1338] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1339,
si_status=0, si_utime=0, si_stime=0} (Child exited) ---
Process 1338 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1338, si_status=0,
si_utime=0, si_stime=1} (Child exited) ---
FAIL
==
FAIL: test_getstatus (__main__.CommandTests)
--
Traceback (most recent call last):
File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 61, in
test_getstatus
self.assertTrue(re.match(pat, commands.getstatus(/.), re.VERBOSE))
AssertionError: None is not True
--
Ran 2 tests in 0.289s
FAILED (failures=1)
Traceback (most recent call last):
File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 70, in module
test_main()
File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 65, in test_main
run_unittest(CommandTests)
File /usr/src/Python-2.7.1/Lib/test/test_support.py, line 1087, in
run_unittest
_run_suite(suite)
File /usr/src/Python-2.7.1/Lib/test/test_support.py, line 1070, in
_run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
File /usr/src/Python-2.7.1/Lib/test/test_commands.py, line 61, in
test_getstatus
self.assertTrue(re.match(pat, commands.getstatus(/.), re.VERBOSE))
AssertionError: None is not True
So, now with strace-4.6, that syscall_293* is shown to be an old strace anomaly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 information. import os import re import sys import commands print commands.getstatus(/.) drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 way, is trying to confirm that what comes back from getstatus is something that looks like the output of ls, so no, it can't really be simplified and still be testing getstatus. It looks like something weird is going on inside the test machinery. Are you willing to do a little Python hacking? If I were seeing this error on my box I'd split up that assert statement. Get the value of the getstatus call, print it out. Then pass the output to the re, and print the result (which should be None, given that the test is failing). If the getstatus output looks right at that point, then something very odd indeed is going on. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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) ... ok
--
Ran 2 tests in 0.068s
OK
[ root@jvdspc:/mnt/sda3/Python-2.7 18:03:34 1686:1179 ]
$ diff -U0 /usr/src/Python-2.7/Lib/test/test_commands.py /tmp/test_commands.py
--- /usr/src/Python-2.7/Lib/test/test_commands.py 2010-03-31
23:01:03.0 +0100
+++ /tmp/test_commands.py 2011-04-28 18:03:27.821395320 +0100
@@ -27,2 +27,2 @@
-self.assertEquals(commands.getoutput('echo xyzzy'), 'xyzzy')
-self.assertEquals(commands.getstatusoutput('echo xyzzy'), (0, 'xyzzy'))
+self.assertEqual(commands.getoutput('echo xyzzy'), 'xyzzy')
+self.assertEqual(commands.getstatusoutput('echo xyzzy'), (0, 'xyzzy'))
@@ -39 +39 @@
-self.assertNotEquals(status, 0)
+self.assertNotEqual(status, 0)
@@ -52,5 +52 @@
-pat = r'''d. # It is a directory.
- \+? # It may have ACLs.
- \s+\d+ # It has some number of links.
- [^/]*# Skip user, group, size, and date.
- /\. # and end with the name of the file.
+pat = r'''^.*(\/\.)[\ ]*[\n\r]*$
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com added the comment: oops, over-eager bash tab again - I've certainly had one too many bash tabs 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 /tmp/test_commands.py --- /usr/src/Python-2.7.1/Lib/test/test_commands.py 2010-11-21 13:34:58.0 + +++ /tmp/test_commands.py 2011-04-28 18:03:27.821395320 +0100 @@ -52,5 +52 @@ -pat = r'''d. # It is a directory. - \+? # It may have ACLs. - \s+\d+ # It has some number of links. - [^/]*# Skip user, group, size, and date. - /\. # and end with the name of the file. +pat = r'''^.*(\/\.)[\ ]*[\n\r]*$ [ root@jvdspc:/mnt/sda3/Python-2.7 18:05:52 1688:1181 ] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 the ending 200a2e - maybe there should not be an 0x20 there . Should I raise a GNU coreutils 8.10 bug about this ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Changes by Jason Vas Dias jason.vas.d...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file21827/bug_11946.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 coreutils 8.12 's ls is wrong to append a ' ', or test_commands.py is wrong not to be expecting it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 *part* of the filename, which it clearly isn't in this case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com added the comment: Oops, Paul is right here - I asked bug-coreut...@gnu.org, and Paul responds: quote Re: bug#8578: 8.12 and 8.10 'ls -dl' appends ' ' (0x20: space) to file output lines From: Paul Eggert egg...@cs.ucla.edu (UCLA Computer Science Department) To: jason.vas.d...@gmail.com CC: 8...@debbugs.gnu.org Date: 2011-04-28 20:34 On 04/28/11 11:34, Jason Vas Dias wrote: $ ls -dl /. | od -cx ... 040 r 2 0 1 5 : 2 8 / . \n 2072303231203a3538322f200a2e 056 Please could the ls developer let me know if it 100% POSIXLY correct that ls appends 0x20 to the filename '/.' here ? I don't see any space appended there. The last four bytes of output are 0x20, 0x2f, 0x2e, 0x0a (space, /, ., newline). Perhaps you're misunderstanding the little-endian nature of od -x output? /quote Yes, of course, when 'od' says ' 2f200a2e' it means it received: 0x20 0x2f 0x2e 0x0a sorry - I'm just trying to understand why your original RE fails - it isn't because of the spaces ! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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. [^/]*# Skip user, group, size, and date. /\. # and end with the name of the file. ''' str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.' if re.match(pat, str, re.VERBOSE) : print MATCHED\n else : print DID NOT MATCH $ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py DID NOT MATCH -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
Jason Vas Dias jason.vas.d...@gmail.com 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 -- type 'exceptions.SystemError': module dl requires
sizeof(int) == sizeof(long) == sizeof(char*)
NO, GEE, THAT'S RIGHT !
( sizeof( int ) == 4 ) == ( ( sizeof(long) == 8) ==
(sizeof(void*) == 8 )
)
which actually makes sense in C on my system, and produces
a true value, ( 1 ) == ( ( 1 ) == ( 1 ) )
when gcc is run with the $CFLAGS given to the python build,
unlike the message's pseudo-code.
So I think some internal python components think they are getting
compiled in 32-bit mode, on a native 64-bit compiler - how ?
Is anything in the python build appending any '-m32' flag ?
Because my environment certainly does not contain '-m32' :
$ export -p | egrep 'CC|CXX|FLAG'
declare -x CC=/usr/bin/gcc
declare -x CFLAGS=-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe
declare -x CXX=/usr/bin/g++
declare -x CXXFLAGS=-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe
`uname -m` says 'x86_64' - a 64-bit arch . And the dl* objects
are actually 64-bit:
$ find . -name 'dl*' -exec file '{}' ';'
./Modules/dlmodule.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not
stripped
./build/temp.linux-x86_64-2.7/usr/src/Python-2.7.1/Modules/_ctypes/libffi/src/dlmalloc.o:
ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
So why this message :
test_dl
test test_dl crashed -- type 'exceptions.SystemError': module dl requires
sizeof(int) == sizeof(long) == sizeof(char*)
hmm, time to get out gdb I guess .
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11946
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11946] 2.7.1 'test_commands' build test fails
R. David Murray rdmur...@bitdance.com 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 to the regex to take into account the selinux extra attributes. My apologies for dragging you through unnecessary debugging :( As for the other issue, please open a new ticket. (The pseudo-code, by the way, is saying that all three sizes must be the same.) -- resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - test_commands.py failing on OS X 10.5.7 due to '@' in ls output ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
