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
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:1
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
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/i
Alex Leach added the comment:
It skips 55, sorry, passing 1659.
--
___
Python tracker
<http://bugs.python.org/issue4130>
___
___
Python-bugs-list mailin
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
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-0
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
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
Changes by Alex Leach :
Added file: http://bugs.python.org/file25221/ffi64.c.patch
___
Python tracker
<http://bugs.python.org/issue4130>
___
___
Python-bugs-list mailin
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 success
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 f
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,
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
>
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
15 matches
Mail list logo
