aixtools added the comment:
On 30-Jul-16 02:51, Martin Panter wrote:
> Martin Panter added the comment:
>
> Looks like your Python 3 build is messed up. Maybe it doesn’t like running
> from a different directory. I would try from the main build directory, and
> note the test_bitfields has an S:
I would not know why - it is just a copy of the sources and then
configure, make, make DESTDIR=/some/where install (rather than make
install).
Same procedure I use for python2.7.
>
> ./python -m unittest -v ctypes.test.test_bitfields
No changes: 3.5.1
root@x064:[/data/prj/aixtools/python/python-3.5.1.2]./python -m unittest
-v ctypes.test.test_bitfields
test_anon_bitfields (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_c_wchar (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_longlong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_1 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_2 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_3 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_4 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_multi_bitfields_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_nonint_types (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_signed (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_single_bitfield_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_big_endian (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_little_endian (ctypes.test.test_bitfields.BitFieldTest)
... ok
test_uint64 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ulonglong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_unsigned (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ints (ctypes.test.test_bitfields.C_Test) ... FAIL
test_shorts (ctypes.test.test_bitfields.C_Test) ... FAIL
======================================================================
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/data/prj/aixtools/python/python-3.5.1.2/Lib/ctypes/test/test_bitfields.py",
line 41, in test_ints
self.assertEqual(getattr(b, name), func(byref(b),
name.encode('ascii')))
AssertionError: -1 != 1
======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/data/prj/aixtools/python/python-3.5.1.2/Lib/ctypes/test/test_bitfields.py",
line 48, in test_shorts
self.assertEqual(getattr(b, name), func(byref(b),
name.encode('ascii')))
AssertionError: -1 != 1
----------------------------------------------------------------------
Ran 19 tests in 0.013s
FAILED (failures=2)
> What I am suggesting as a fix is to change line 381 from plain “int” to
> “signed int”, and 382 to “signed short”. I can make a patch later if that
> will help. Hopefully with these changes the C compiler will use signed
> integer logic, matching what I believe the ctypes library uses for c_int and
> c_short.
Working from Python-2.7.12 - added your changes, test still fails:
root@x064:[/data/prj/aixtools/python/python-2.7.12.0]./python -m
unittest -v ctypes.test.test_bitfields
test_anon_bitfields (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_c_wchar (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_longlong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_1 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_2 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_3 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_mixed_4 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_multi_bitfields_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_nonint_types (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_signed (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_single_bitfield_size (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_big_endian (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_uint32_swap_little_endian (ctypes.test.test_bitfields.BitFieldTest)
... ok
test_uint64 (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ulonglong (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_unsigned (ctypes.test.test_bitfields.BitFieldTest) ... ok
test_ints (ctypes.test.test_bitfields.C_Test) ... ok
test_shorts (ctypes.test.test_bitfields.C_Test) ... FAIL
======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/data/prj/aixtools/python/python-2.7.12.0/Lib/ctypes/test/test_bitfields.py",
line 48, in test_shorts
self.assertEqual((name, i, getattr(b, name)), (name, i,
func(byref(b), name)))
AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1)
First differing element 2:
-1
1
- ('M', 1, -1)
? -
+ ('M', 1, 1)
----------------------------------------------------------------------
Ran 19 tests in 0.068s
FAILED (failures=1)
> Using a type other than short is not right, because the Python test is
> explicitly trying to test c_short behaviour. If your compiler does not
> support “signed short” bitfields, maybe we just have to accept that ctypes
> supports it even though the compiler doesn’t, and skip the test.
Looks like this may be the approach: as signed int, signed short give
the same message - it seems that xlc (and maybe Sun C) does not accept
"short" as a bitfield type.
skipping test - only if compiler is not gcc, as when using gcc, test
works fine.
> ----------
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue27643>
> _______________________________________
----------
nosy: +aixto...@gmail.com
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27643>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
