[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 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 <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 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 <http://bugs.python.org/issue11946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11458] tarfile with socket incompatability
New submission from Alex Leach :
Hi,
I'm trying to parse the contents of tar archives (.tgz) on the fly, and failing
to do so. The tar archives in question have directory hierarchies, and only if
a TarInfo object is a file (.isreg() ) will I try and read it's contents.
I figured a sensible idea would be to pass a socket(.makefile()) object to the
fileobj attribute of tarfile.open. This doesn't work because a socket file
descriptor does not have a tell() method. I understand that a socket object
shouldn't need to have a tell method, but why should the fileobj passed to
tarfile.open need it?
Code:-
def get_headers( self, file_name ):
sock = socket.socket()
sock.bind(('localhost',0))
fd = sock.makefile()
handle = tarfile.open( file_name,'r',fileobj=fd ) # This line breaks
I'm currently testing on Python v2.6.6 EPD 6.3-2 64 bit, on an Autumn 2010 Mac
Pro.
My dirty bug-fix idea is to subclass tarfile.TarFile, and give it a tell()
method, to just return 0. I don't want to have to do that. Any alternative
suggestions would be greatly appreciated.
Cheers,
Alex
--
components: Extension Modules
messages: 130482
nosy: Alex.Leach
priority: normal
severity: normal
status: open
title: tarfile with socket incompatability
___
Python tracker
<http://bugs.python.org/issue11458>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11458] tarfile with socket incompatability
Alex Leach added the comment: Thanks! =D On Thu, Mar 10, 2011 at 3:46 AM, R. David Murray wrote: > > R. David Murray added the comment: > > I believe you are looking for mode 'r|'. > > -- > nosy: +r.david.murray > resolution: -> works for me > stage: -> committed/rejected > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue11458> > ___ > -- Added file: http://bugs.python.org/file21069/unnamed ___ Python tracker <http://bugs.python.org/issue11458> ___Thanks! =DOn Thu, Mar 10, 2011 at 3:46 AM, R. David Murray <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: R. David Murray <mailto:rdmur...@bitdance.com";>rdmur...@bitdance.com> added the comment: I believe you are looking for mode 'r|'. -- nosy: +r.david.murray resolution: Â -> works for me stage: Â -> committed/rejected status: open -> closed ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue11458"; target="_blank">http://bugs.python.org/issue11458> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment: Patch included for Modules/_ctyles/libffi/src/x86/ffi64.c. I've added some include guards around anything necessary to compile with the Intel compiler. This patch is needed to compile the _ctypes module with icc on current Python releases (just successfully compiled 2.7.3, with patch).. -- keywords: +patch nosy: +Alex.Leach Added file: http://bugs.python.org/file25205/ffi64.c.patch ___ Python tracker <http://bugs.python.org/issue4130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Changes by Alex Leach : Added file: http://bugs.python.org/file25221/ffi64.c.patch ___ Python tracker <http://bugs.python.org/issue4130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment:
Submitting a working patch upstream would make sense.. Just found, downloaded
and tried compiling libffi-3.0.11. The developers have made some changes
towards a solution, but compilation fails with the same error:-
libtool: compile: icc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude
-I../src -DFFI_BUILDING -g -O3 -ansi_alias -Wall -fexceptions -MT
src/x86/ffi64.lo -MD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c
-fPIC -DPIC -o src/x86/.libs/ffi64.o
../src/x86/ffi64.c(50): error: identifier "__m128" is undefined
UINT128 sse[MAX_SSE_REGS];
__m128 is defined in Intel's xmmintrin.h though
[http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/intref_cls/common/intref_sse_arithmetic.htm].
So I added the necessary include line, which gets a different error:-
libtool: compile: icc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude
-I../src -DFFI_BUILDING -g -O3 -ansi_alias -Wall -fexceptions -MT
src/x86/ffi64.lo -MD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c
-fPIC -DPIC -o src/x86/.libs/ffi64.o
../src/x86/ffi64.c(481): error: a value of type "UINT64={unsigned long}" cannot
be assigned to an entity of type "__m128"
reg_args->sse[ssecount++] = *(UINT64 *) a;
^
../src/x86/ffi64.c(484): error: a value of type "UINT32={unsigned int}" cannot
be assigned to an entity of type "__m128"
reg_args->sse[ssecount++] = *(UINT32 *) a;
^
Regarding my previous patch, I'm not convinced it works actually.. It compiles,
and passes the default Python tests, but I get some dodgy behaviour. e.g. when
compiling 2.7.3 with --enable-shared, I get a segfault when compiling the gdbm
module against libdb4.8-dev. Any specific ways of testing the build?
--
___
Python tracker
<http://bugs.python.org/issue4130>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment: Thanks for the assurance. I found it strange because compilation only fails when building shared binaries. My static build of Python-2.7.3, with icc seems to work fine, except for this libffi issue. Turns out I needed dejagnu to run the tests in libffi's `make check`, which is why it passed before when it shouldn't have. I'll liaise with the libffi authors to try and come up with a working solution. -- ___ Python tracker <http://bugs.python.org/issue4130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment: I hadn't tried the `long long` substitution before, but unfortunately I don't think that simple fix quite does the trick. I just checked out libffi from git, and made the following patch:- #$ diff -u ffi64.c ffi64.c.orig --- ffi64.c 2012-07-16 11:38:44.237255615 +0100 +++ ffi64.c.orig2012-07-16 11:38:34.681045084 +0100 @@ -38,7 +38,7 @@ #define MAX_SSE_REGS 8 #ifdef __INTEL_COMPILER -#define UINT128 long long +#define UINT128 __m128 #else #define UINT128 __int128_t #endif It compiles fine, but `make check` returns a lot of FAIL's, and a quite a few of the tests timeout. e.g. FAIL: libffi.special/unwindtest.cc -shared-libgcc -lstdc++ execution test WARNING: program timed out. It's probably also worth mentioning that I'm now using icc version 12.1.4 Cheers, Alex On Monday 16 Jul 2012 09:53:36 Stefan Krah wrote: > Stefan Krah added the comment: > > Ah, forget that: Alex has apparently already tested that patch. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue4130> > ___ -- ___ Python tracker <http://bugs.python.org/issue4130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment:
I just had a dig around my cpython build dir, and found an ffi64.c I hacked at
a
while back.
I copied the edits over to the latest libffi git revision, rebuilt, and `make
check` (of libffi) passes all tests. So as far as I can tell the below patch
works, but it is a hack, and I'm sure it could be improved..
Regards to submitting it upstream, I've just written to the libffi-
discuss/sourceware.org mailing list, sending them the below patch also. So it
might work, but you know that GPL clause about coming with no warranty? ;)
HTH,
Alex
libffi-git> diff -u src/x86/ffi64.c.orig src/x86/ffi64.c
--- src/x86/ffi64.c.orig2012-07-16 11:38:34.681045084 +0100
+++ src/x86/ffi64.c 2012-07-16 22:34:42.959552750 +0100
@@ -38,7 +38,7 @@
#define MAX_SSE_REGS 8
#ifdef __INTEL_COMPILER
-#define UINT128 __m128
+typedef struct { int64_t m[2]; } __int128_t;
#else
#define UINT128 __int128_t
#endif
@@ -47,7 +47,7 @@
{
/* Registers for argument passing. */
UINT64 gpr[MAX_GPR_REGS];
- UINT128 sse[MAX_SSE_REGS];
+ __int128_t sse[MAX_SSE_REGS];
};
extern void ffi_call_unix64 (void *args, unsigned long bytes, unsigned flags,
@@ -477,10 +477,20 @@
break;
case X86_64_SSE_CLASS:
case X86_64_SSEDF_CLASS:
+#ifdef __INTEL_COMPILER
+ reg_args->sse[ssecount].m[0] = *(UINT64 *) a;
+ reg_args->sse[ssecount++].m[1] = 0;
+#else
reg_args->sse[ssecount++] = *(UINT64 *) a;
+#endif
break;
case X86_64_SSESF_CLASS:
+#ifdef __INTEL_COMPILER
+ reg_args->sse[ssecount].m[0] = *(UINT32 *) a;
+ reg_args->sse[ssecount++].m[1] = 0;
+#else
reg_args->sse[ssecount++] = *(UINT32 *) a;
+#endif
break;
default:
abort();
--
___
Python tracker
<http://bugs.python.org/issue4130>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment: It skips 55, sorry, passing 1659. -- ___ Python tracker <http://bugs.python.org/issue4130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
Alex Leach added the comment: That's the same patch as I attached before actually, so sorry for the spam.. -- ___ Python tracker <http://bugs.python.org/issue4130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8
Alex Leach added the comment: The configure.ac patch works for me, on x86_64 Arch Linux. I just updated to GCC-4.8.0 and came across an overwhelming number of these warnings when compiling extension modules. Thanks for the simple fix David. Tested on hg branch 2.7; the testsuite completes without error. -- nosy: +Alex.Leach versions: -Python 2.6, Python 2.7, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue17547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4934] tp_del and tp_version_tag undocumented
Alex Leach added the comment: I've just ran into tp_version_tag, when running the boost python testsuite and wondered what it was... Since upgrading to GCC 4.8, I've started to get a lot more warnings with Python extensions, e.g.:- boost/python/opaque_pointer_converter.hpp:122:14: warning: missing initializer for member ‘_typeobject::tp_version_tag’ [-Wmissing-field-initializers] In this instance the testsuite was made to compile with the '-Wextra' flag. The fix was pretty simple; add another zero to the opaque_pointer_convert struct. I have used the following preprocessor macro to test whether or not to do this. Would this be a good way to test for the addition? #if PY_VERSION_HEX >= 0x0206 0,/* tp_version_tag */ #endif Cheers, Alex -- nosy: +Alex.Leach ___ Python tracker <http://bugs.python.org/issue4934> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8
Alex Leach added the comment: I don't think I can tell you anything you don't know already, but ... On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm wrote: > BTW, is that GCC format checking code available anywhere? Is this what you mean? http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/c-family/c-format.c?annotate=193304&pathrev=193304 I got taken straight there from the link you sent, above... > > Am I right in thinking that it was an out-of-tree patch to GCC, from the > pre-plugin days? No idea.. GCC plugins have been around for several years now, though and the patch was only introduced in November. If this patch was applied to any past GCC distributions, I'm sure someone else would have been overwhelmed with warnings and would have mentioned something before now. Either way, it looks like the patch is going to stay. In case you hadn't seen it already, the invoke.texi source file probably has the most descriptive changes:- http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/doc/invoke.texi?r1=193304&r2=193303&pathrev=193304 KR, Alex -- ___ Python tracker <http://bugs.python.org/issue17547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
