libffi update to 3.0.9

[doko42]

BPO	8142
Nosy	@loewis, @theller, @doko42, @vstinner, @ned-deily, @florentx
Files	libffi-update3.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/doko42'
closed_at = <Date 2010-08-08.21:51:05.644>
created_at = <Date 2010-03-14.23:40:04.385>
labels = ['ctypes', 'type-feature']
title = 'libffi update to 3.0.9'
updated_at = <Date 2010-08-08.21:51:05.643>
user = 'https://github.com/doko42'

bugs.python.org fields:

activity = <Date 2010-08-08.21:51:05.643>
actor = 'flox'
assignee = 'doko'
closed = True
closed_date = <Date 2010-08-08.21:51:05.644>
closer = 'flox'
components = ['ctypes']
creation = <Date 2010-03-14.23:40:04.385>
creator = 'doko'
dependencies = []
files = ['16590']
hgrepos = []
issue_num = 8142
keywords = ['patch', 'buildbot']
message_count = 18.0
messages = ['101072', '101104', '101134', '101219', '101221', '101230', '101263', '101264', '101322', '101330', '101335', '101338', '101340', '101491', '101492', '106061', '107618', '113332']
nosy_count = 8.0
nosy_names = ['loewis', 'theller', 'doko', 'vstinner', 'ned.deily', 'akrpic77', 'nick', 'flox']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue8142'
versions = ['Python 2.7', 'Python 3.2']

[doko42]

opening a report to track issues with the update of the internal libffi copy to 3.0.9. will commit this update to the trunk, and later to the py3k branch.

[doko42]

updated on the trunk and the py3k branch

[florentx]

I noticed some failures on Sparc Solaris10 buildbots (both trunk and 3.x)

======================================================================
FAIL: test_ulonglong (ctypes.test.test_callbacks.Callbacks)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

---

Ran 325 tests in 3.088s

FAILED (failures=1)
test test_ctypes failed -- Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 68, in test_ulonglong
    self.check_type(c_ulonglong, 42)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/ctypes/test/test_callbacks.py", line 31, in check_type
    self.assertEqual(result, arg)
AssertionError: 0L != 42

[florentx]

re-opened to track the issue on Sparc Solaris

[doko42]

no access to solaris hardware. please could you run the libffi testsuite on this machine? make sure that expect is installed.

[doko42]

the ports which are maintained separately still need an update:

libffi_msvc
libffi trunk now has a port to x86/msvc. might require some
extra updates from libffi.

libffi_osx:
3.0.9 has support for darwin on powerpc and x86

libffi_wince:
same, support seems to be included.

[theller]

the ports which are maintained separately still need an update:

libffi_msvc
libffi trunk now has a port to x86/msvc. might require some
extra updates from libffi.

I'll take care of this one.
Would it be a good idea to upgrade to libffi trunk
in Modules/_ctypes/libffi, and get rid of the libffi_msvc
fork completely (by applying an additional small patch)?

[florentx]

no access to solaris hardware. please could you run the libffi
testsuite on this machine? make sure that expect is installed.

I don't have access to such hardware.
I noticed the buildbot failures since libffi was upgraded.

[ned-deily]

(Adding Ronald for OS X.)

[doko42]

On 18.03.2010 16:44, Thomas Heller wrote:

Thomas Heller<theller@ctypes.org> added the comment:

> the ports which are maintained separately still need an update:
>
> libffi_msvc
> libffi trunk now has a port to x86/msvc. might require some
> extra updates from libffi.

I'll take care of this one.
Would it be a good idea to upgrade to libffi trunk
in Modules/_ctypes/libffi, and get rid of the libffi_msvc
fork completely (by applying an additional small patch)?

I'm attaching the patch for an update from the trunk; it passes the ctypes tests and the libffi testsuite on i486-linux-gnu.

We should revert the following chunk for configure.ac to generate the Makefile's again, so that we are able to run the testsuite at least with dejagnu:

-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/ffi.h)

[theller]

We should revert the following chunk for configure.ac to generate the Makefile's again, so that we are able to run the testsuite at least with dejagnu:

-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/ffi.h)

Can you make this change, run autoconf (I have only version 2.64 but 2.65 is needed), and commit please?

[doko42]

Can you make this change, run autoconf, and commit please?

done, and updated the patch for the merge from the trunk.

[theller]

done, and updated the patch for the merge from the trunk.

----------
Added file: http://bugs.python.org/file16590/libffi-update3.diff

This patch passes the ctypes tests and libffi testsuite on this system:

Linux tubu64 2.6.24-27-generic #1 SMP Fri Mar 12 00:52:19 UTC 2010 x86_64 GNU/Linux

Please apply. And thanks for all the help...

[florentx]

See this post, about Solaris failure:
http://bugs.python.org/issue1544339#msg101485

And the proposed patch:
http://sourceware.org/ml/libffi-discuss/2010/msg00016.html

[florentx]

Ignore my last comment. It is not relevant, and the patch is already in 3.0.9.

[florentx]

It seems fixed now.

[vstinner]

Reopen the issue: libffi compilation fails on "x86 FreeBSD 3.x" buildbot.

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%203.x/builds/349/steps/compile/logs/stdio

gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.2-pydebug/libffi/include -Ibuild/temp.freebsd-6.4-RELEASE-i386-3.2-pydebug/libffi -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src -IInclude -I./Include -I/usr/local/include -I/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Include -I. -c /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.freebsd-6.4-RELEASE-i386-3.2-pydebug/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.o
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S: Assembler messages:
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S:360: Error: junk at end of line, first unrecognized character is @' /usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S:387: Error: junk at end of line, first unrecognized character is @'
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Modules/_ctypes/libffi/src/x86/sysv.S:423: Error: junk at end of line, first unrecognized character is `@'

[florentx]

"x86 FreeBSD 3.x" buildbot seems to compile "libffi".