Marc-Andre Lemburg added the comment:
Here's a patch which I have tested on Linux, FreeBSD and Mac OS X.
It solves the problem with compiling in Windows calls on non-Windows platforms
and resynchronizes the ffi_raw_call() function with the ffi_call()
implementation. Both functions had the
Roundup Robot added the comment:
New changeset a04b3de18c4c by Benjamin Peterson in branch '3.4':
fix libffi compilation on FreeBSD (#23042)
https://hg.python.org/cpython/rev/a04b3de18c4c
New changeset 987b30a88653 by Benjamin Peterson in branch 'default':
merge 3.4 (#23042)
Changes by Benjamin Peterson benja...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23042
___
Benjamin Peterson added the comment:
Let's see what the buildbots think.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23042
___
___
Roundup Robot added the comment:
New changeset 96a7b401d5e4 by Benjamin Peterson in branch '2.7':
fix libffi compilation on FreeBSD (#23042)
https://hg.python.org/cpython/rev/96a7b401d5e4
--
nosy: +python-dev
___
Python tracker rep...@bugs.python.org
koobs added the comment:
See also:
Issue: https://github.com/atgreen/libffi/issues/180
Title: OSX/i386 build is broken in v3.2.1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23042
___
Marc-Andre Lemburg added the comment:
@koobs: I was just looking at the 3.2.1 code where it still looks like
ffi_call_win32() gets called even on non-Win32 platforms.
That said, it's possible that ffi_call_win32() is indeed defined on other
platforms than Win32 as well in 3.2.1 - after all,
koobs added the comment:
@marc I took a look at the code upstream and it does indeed appear to be the
same. It was introduced in 3.1 [1].
I cant explain however how or why our Python ports work with libffi 3.2.1.
See msg238767 for a link to another similar (same?) issue, with failure of OSX
koobs added the comment:
@Marc, if upstream 3.2.1 also has the issue, then that would mean the current
FreeBSD Python ports, which use --use-system-ffi and the security/libffi port,
currently at version 3.2.1 [1], can reproduce the issue.
I'm not aware of reports that they fail in this
