Repository navigation
Update libffi to 3.4.2 #89185
Copy link
Copy link
Closed
Labels
3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes3.9 (EOL)end of lifeend of lifeOS-windowsbuildThe build process and cross-buildThe build process and cross-buildtopic-ctypestype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
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 = None
closed_at = <Date 2021-09-09.21:03:07.969>
created_at = <Date 2021-08-26.21:13:17.382>
labels = ['type-bug', '3.9', '3.10', '3.11', 'ctypes', 'build', 'OS-windows']
title = 'Update libffi to 3.4.2'
updated_at = <Date 2021-09-13.14:45:40.034>
user = 'https://github.com/zooba'bugs.python.org fields:
activity = <Date 2021-09-13.14:45:40.034>
actor = 'zach.ware'
assignee = 'none'
closed = True
closed_date = <Date 2021-09-09.21:03:07.969>
closer = 'steve.dower'
components = ['Build', 'Windows', 'ctypes']
creation = <Date 2021-08-26.21:13:17.382>
creator = 'steve.dower'
dependencies = []
files = []
hgrepos = []
issue_num = 45022
keywords = ['patch']
message_count = 13.0
messages = ['400382', '400383', '400385', '400430', '400431', '400432', '401004', '401012', '401013', '401330', '401518', '401696', '401704']
nosy_count = 9.0
nosy_names = ['paul.moore', 'tim.golden', 'ned.deily', 'lukasz.langa', 'zach.ware', 'steve.dower', 'pablogsal', 'miss-islington', 'Ghostkeeper']
pr_nums = ['27982', '27984', '27985', '28001', '28146']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue45022'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']Metadata
Metadata
Assignees
Labels
3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes3.9 (EOL)end of lifeend of lifeOS-windowsbuildThe build process and cross-buildThe build process and cross-buildtopic-ctypestype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Activity
zooba commentedon Aug 26, 2021
libffi is doing releases again! We're a few versions behind, so should pull in the latest. https://github.com/libffi/libffi/
Adding RMs for opinions on backporting, and Ned in case this impacts the macOS build.
2 remaining items
miss-islington commentedon Aug 27, 2021
New changeset 399cd46 by Miss Islington (bot) in branch '3.9':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982)
399cd46
miss-islington commentedon Aug 27, 2021
New changeset db36fdb by Miss Islington (bot) in branch '3.10':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982)
db36fdb
zooba commentedon Aug 27, 2021
Realised that 3.8 needs the change to ensure it keeps using the same build of libffi. Obviously it won't be getting the new one (and since the new one is apparently a new API version, it may not even go into 3.10).
ambv commentedon Sep 3, 2021
New changeset 8c3a10e by Steve Dower in branch '3.8':
bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982) (GH-28001)
8c3a10e
zooba commentedon Sep 3, 2021
New changeset 6f8bc46 by Steve Dower in branch 'main':
bpo-45022: Update libffi to 3.4.2 in Windows build (GH-28146)
6f8bc46
zooba commentedon Sep 3, 2021
So on one hand, this change applies cleanly and it appears nothing needs to change to adopt the newer version.
On the other hand, because the libffi DLL has a different name, it changes the layout on disk. I know we don't do that (except in exceptional circumstances) after beta, but perhaps this one is safe enough? We certainly don't "support" directly accessing the libffi DLL, but it still could break users (if, for example, they load another native module that implicitly used the older libffi and would now fail to load when it's missing).
Any thoughts?
zooba commentedon Sep 7, 2021
New changeset 4dc4300 by giovanniwijaya in branch 'main':
bpo-45022: Fix libffi DLL name in Windows installer sources (GH-28203)
4dc4300
zooba commentedon Sep 9, 2021
Going to just decide that we won't backport the update. If a big enough security issue is found we can consider it, but it would have to justify the potential-but-unlikely breaking change for users who are relying on the name of the DLL.
Ghostkeeper commentedon Sep 13, 2021
It seems this just broke our Windows build process of Python 3.8, since the cpython-bin-deps repository now contains only a libffi-8.lib while the the Python 3.8 branch still refers to libffi-7.lib in libffi.props:
cpython/PCbuild/libffi.props
Line 13 in 5a42a49
zware commentedon Sep 13, 2021
The 3.8 branch has been updated to point to the
libffi-3.3.0tag; you can either update to the latest revision of 3.8 or pull in just 8c3a10eitachaaa commentedon Apr 23, 2024
It seems that libffi-3.4.2 is not supported by CPython 3.8, 3.9, and 3.10. Will this be considered later, Or wo have to have 3.11 to start supporting 3.4.2?
iwannastay commentedon Apr 23, 2024
Do you mean that the version 3.9 of python dont support version 3.4.x of libffi?
#118171
We encountered a coredump with the versions above.