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.

Author ned.deily
Recipients ned.deily, pda, rosslagerwall
Date 2020-05-08.01:51:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1588902661.18.0.771778751514.issue14527@roundup.psfhosted.org>
In-reply-to
Content
As of current Python 3 releases, like 3.8, the python build no longer vendors a copy of libffi for most Unix systems and for those systems the --with-system-ffi configure option is ignored, i.e. configure and setup.py will always try to find an external libffi.  On most systems, if you use are OK with using the system-supplied libffi, building and execution should usually "just work".  But if you want to use another version of libffi, for example, one that you build from source, it can be very non-intuitive of how to successfully do that *especially* if there is already a system libffi installed.  Depending on the system, you may need to set environment build variables like LDFLAGS, CFLAGS or PKG_CONFIG_PATH, and LD_LIBRARY_PATH for the Python build and/or you might need to override some of the libffi build variables to install in the proper locations for your system.  It seems like, as has been suggested in various places, setup.py should at least try to use pkg-config to find libffi library locations as it already does to find libffi include files. But that might not be enough to get a working setup, i.e. you still might need to set LD_LIBRARY_PATH or the equivalent to find libffi. At the very least, there should be some documentation on how to build with a non-system libffi.
History
Date User Action Args
2020-05-08 01:51:01ned.deilysetrecipients: + ned.deily, rosslagerwall, pda
2020-05-08 01:51:01ned.deilysetmessageid: <1588902661.18.0.771778751514.issue14527@roundup.psfhosted.org>
2020-05-08 01:51:01ned.deilylinkissue14527 messages
2020-05-08 01:51:00ned.deilycreate