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 zach.ware
Recipients Arfrever, berker.peksag, chris.jerdonek, doko, fabiovmp, gustavotemple, koobs, lemburg, meador.inge, r.david.murray, steve.dower, tim.golden, xdegaye, yan12125, zach.ware
Date 2016-07-27.22:28:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469658487.02.0.0371790673729.issue23085@psf.upfronthosting.co.za>
In-reply-to
Content
OSX and Windows are both exempt from this discussion.  Each has its own private copy of an ancient version of libffi: Modules/_ctypes/libffi_osx/ and Modules/_ctypes/libffy_msvc/.

I would be in favor of switching to --with-system-ffi by default for 3.6 and deprecating building with the bundled full copy of libffi (Modules/_ctypes/libffi/), to be removed in 3.7.  OSX would also default to --with-system-ffi, but would still fall back to its private copy when a system copy isn't available.

It seems like most Linux and BSD distributions would be better off with system-ffi.  I'm not sure how cross-builds would have to deal with things in 3.7, but they already have to deal with dependencies like openssl, bz2, and lzma; adding libffi to that mix shouldn't be that big of a deal.

Adding Ned to confirm that building OSX installers wouldn't be affected as long as we don't touch Modules/_ctypes/libffi_osx/ and there's not a system copy of libffi available.
History
Date User Action Args
2016-07-27 22:28:07zach.waresetrecipients: + zach.ware, lemburg, doko, tim.golden, Arfrever, r.david.murray, meador.inge, chris.jerdonek, xdegaye, berker.peksag, koobs, steve.dower, gustavotemple, fabiovmp, yan12125
2016-07-27 22:28:07zach.waresetmessageid: <1469658487.02.0.0371790673729.issue23085@psf.upfronthosting.co.za>
2016-07-27 22:28:07zach.warelinkissue23085 messages
2016-07-27 22:28:06zach.warecreate