Skip to content

Update libffi to 3.4.2 #89185

Closed
Closed

Description

@zooba
BPO 45022
Nosy @pfmoore, @tjguk, @ned-deily, @ambv, @zware, @zooba, @pablogsal, @miss-islington, @Ghostkeeper
PRs
  • bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update #27982
  • [3.10] bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982) #27984
  • [3.9] bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982) #27985
  • [3.8] bpo-45022: Pin current libffi build to fixed version in preparation for upcoming update (GH-27982) #28001
  • bpo-45022: Update libffi to 3.4.2 in Windows build #28146
  • 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']

    Activity

    1. zooba commented on Aug 26, 2021

      @zooba
      MemberAuthor

      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. 2 remaining items

    3. miss-islington commented on Aug 27, 2021

      @miss-islington
      Contributor

      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

    4. miss-islington commented on Aug 27, 2021

      @miss-islington
      Contributor

      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

    5. zooba commented on Aug 27, 2021

      @zooba
      MemberAuthor

      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).

    6. ambv commented on Sep 3, 2021

      @ambv
      Contributor

      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

    7. zooba commented on Sep 3, 2021

      @zooba
      MemberAuthor

      New changeset 6f8bc46 by Steve Dower in branch 'main':
      bpo-45022: Update libffi to 3.4.2 in Windows build (GH-28146)
      6f8bc46

    8. zooba commented on Sep 3, 2021

      @zooba
      MemberAuthor

      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?

    9. zooba commented on Sep 7, 2021

      @zooba
      MemberAuthor

      New changeset 4dc4300 by giovanniwijaya in branch 'main':
      bpo-45022: Fix libffi DLL name in Windows installer sources (GH-28203)
      4dc4300

    10. zooba commented on Sep 9, 2021

      @zooba
      MemberAuthor

      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.

    11. Ghostkeeper commented on Sep 13, 2021

      Ghostkeepermannequin
      Mannequin

      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:

      <_LIBFFIDLL Include="$(libffiOutDir)\libffi-7.dll" />

    12. zware commented on Sep 13, 2021

      @zware
      Member

      The 3.8 branch has been updated to point to the libffi-3.3.0 tag; you can either update to the latest revision of 3.8 or pull in just 8c3a10e

    13. transferred this issue fromon Apr 10, 2022
    14. itachaaa commented on Apr 23, 2024

      @itachaaa

      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?

    15. iwannastay commented on Apr 23, 2024

      @iwannastay

      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.

      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.

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions