This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: python fails to locate system libffi
Type: compile error Stage: resolved
Components: Build Versions: Python 3.7, Python 3.6, Python 3.5, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: christian.heimes, python-dev, rkuska, vstinner
Priority: high Keywords: patch

Created on 2016-03-29 10:09 by rkuska, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
00184-ctypes-should-build-with-libffi-multilib-wrapper.patch rkuska, 2016-03-29 10:09
Pull Requests
URL Status Linked Edit
PR 552 closed dstufft, 2017-03-31 16:36
Messages (4)
msg262598 - (view) Author: Robert Kuska (rkuska) * Date: 2016-03-29 10:09
Python fails to locate system version of ffi when building. We delete bundled version of ffi and build process fail with following error:

error: [Errno 2] No such file or directory: '/builddir/build/BUILD/Python-3.5.1/Modules/_ctypes/libffi'

This is caused by setup.py@1993 checking only for '#define LIBFFI_H' within ffi.h.

Content of /usr/include/ffi.h:

> $ cat /usr/include/ffi.h
/* This file is here to prevent a file conflict on multiarch systems. */
#ifdef ffi_wrapper_h
#error "Do not define ffi_wrapper_h!"
#endif
#define ffi_wrapper_h

#if defined(__i386__)
#include "ffi-i386.h"
#elif defined(__powerpc64__)
#include "ffi-ppc64.h"
#elif defined(__powerpc__)
#include "ffi-ppc.h"
#elif defined(__s390x__)
#include "ffi-s390x.h"
#elif defined(__s390__)
#include "ffi-s390.h"
#elif defined(__x86_64__)
#include "ffi-x86_64.h"
#else
#error "The libffi-devel package is not usable with the architecture."
#endif

#undef ffi_wrapper_h

It is important to note that this content is Fedora specific. As a workaround we (Fedora) use attached patch.

Would it be plausible to accept this patch in upstream?
msg276885 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-18 12:23
This affects Python 3.7 because our own copy of libffi was removed from 'default'.
msg276887 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-09-18 12:40
New changeset c4cec8f7c727 by Christian Heimes in branch '3.5':
Issue #26661: setup.py now detects system libffi with multiarch wrapper.
https://hg.python.org/cpython/rev/c4cec8f7c727

New changeset 18825546acbc by Christian Heimes in branch '3.6':
Issue #26661: setup.py now detects system libffi with multiarch wrapper.
https://hg.python.org/cpython/rev/18825546acbc

New changeset 35820a4a6967 by Christian Heimes in branch 'default':
Issue #26661: setup.py now detects system libffi with multiarch wrapper.
https://hg.python.org/cpython/rev/35820a4a6967

New changeset 2a3e4fa42464 by Christian Heimes in branch '2.7':
Issue #26661: setup.py now detects system libffi with multiarch wrapper.
https://hg.python.org/cpython/rev/2a3e4fa42464
msg276888 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-18 12:41
Thanks Robert, I have been running into the same issue for a while.
History
Date User Action Args
2022-04-11 14:58:29adminsetgithub: 70848
2017-03-31 16:36:25dstufftsetpull_requests: + pull_request988
2016-09-18 12:41:39christian.heimessetstatus: open -> closed
resolution: fixed
messages: + msg276888

stage: resolved
2016-09-18 12:40:27python-devsetnosy: + python-dev
messages: + msg276887
2016-09-18 12:23:56christian.heimessetpriority: normal -> high

nosy: + christian.heimes
versions: + Python 2.7, Python 3.5, Python 3.6, Python 3.7
messages: + msg276885

assignee: christian.heimes
2016-03-29 21:59:21vstinnersetnosy: + vstinner
2016-03-29 10:09:12rkuskacreate