Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove distributed copy of libffi #56290

Closed
benjaminp opened this issue May 15, 2011 · 11 comments
Closed

Remove distributed copy of libffi #56290

benjaminp opened this issue May 15, 2011 · 11 comments

Comments

@benjaminp
Copy link
Contributor

BPO 12081
Nosy @loewis, @birkenfeld, @doko42, @jcea, @amauryfa, @abalkin, @pitrou, @benjaminp, @merwok, @briancurtin, @meadori
Superseder
  • bpo-15194: libffi-3.0.11 update
  • 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 2012-07-08.17:39:48.546>
    created_at = <Date 2011-05-15.15:37:05.563>
    labels = ['ctypes']
    title = 'Remove distributed copy of libffi'
    updated_at = <Date 2012-07-08.17:39:48.545>
    user = 'https://github.com/benjaminp'

    bugs.python.org fields:

    activity = <Date 2012-07-08.17:39:48.545>
    actor = 'loewis'
    assignee = 'none'
    closed = True
    closed_date = <Date 2012-07-08.17:39:48.546>
    closer = 'loewis'
    components = ['ctypes']
    creation = <Date 2011-05-15.15:37:05.563>
    creator = 'benjamin.peterson'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 12081
    keywords = []
    message_count = 11.0
    messages = ['136034', '136035', '136049', '136050', '136659', '158313', '158325', '158430', '158544', '165027', '165029']
    nosy_count = 15.0
    nosy_names = ['loewis', 'georg.brandl', 'doko', 'jcea', 'amaury.forgeotdarc', 'belopolsky', 'pitrou', 'nadeem.vawda', 'benjamin.peterson', 'eric.araujo', 'rpetrov', 'Arfrever', 'brian.curtin', 'meador.inge', 'rosslagerwall']
    pr_nums = []
    priority = 'normal'
    resolution = 'duplicate'
    stage = None
    status = 'closed'
    superseder = '15194'
    type = None
    url = 'https://bugs.python.org/issue12081'
    versions = ['Python 3.3']

    @benjaminp
    Copy link
    Contributor Author

    I believe the bugs which the patched version of libffi used have been fixed in recent versions. We should stop distributing an old version.

    @birkenfeld
    Copy link
    Member

    Sounds reasonable. How will this work on Windows?

    @rpetrov
    Copy link
    Mannequin

    rpetrov mannequin commented May 15, 2011

    On windows work with patched version of library . Unpatched does not work but I cannot remember python issue number.

    @Arfrever
    Copy link
    Mannequin

    Arfrever mannequin commented May 15, 2011

    Has the patch been sent to libffi upstream? What was the response from libffi upstream?

    @doko42
    Copy link
    Member

    doko42 commented May 23, 2011

    iirc after merging 3.0.9, we still had to use the internal libffi bits for windows and macosx. I didn't check 3.0.10rc8

    @rosslagerwall
    Copy link
    Mannequin

    rosslagerwall mannequin commented Apr 15, 2012

    In any case, it should be OK to remove libffi_arm_wince?

    Is WinCE supported?

    @pitrou
    Copy link
    Member

    pitrou commented Apr 15, 2012

    I don't think we have ever "supported" WinCE (which is apparently named "Windows Embedded Compact 7" nowadays). It only provides a subset of the Win32 API so the current tree may not even compile.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Apr 16, 2012

    Arfrever: I doubt anybody has contributed patches back, or that anybody is interested in doing so.

    I personally don't see a problem in using an old libffi version, so I fail to see Benjamin's issue. Figuring out how exactly to use the system libffi is more hassle than keeping our own copy.

    Please understand that ctypes is unmaintained. Anybody actively taking over maintenance of ctypes would have to decide on how integration with libffi is supposed to work. Without a maintainer, falling back to the sytem libffi is a too high risk, IMO, since this will certainly produce tons of new bug reports, with nobody prepared to deal with them.

    @doko42
    Copy link
    Member

    doko42 commented Apr 17, 2012

    The last time I merged libffi, we were not able to build the MacOS X and Windows libffi from the upstream sources, but used the internal copy of the copy. Now that libffi 3.0.11 is released, we could

    • update to this new version, see if the MacOS X and Windows
      builds work (there are upstream related changes)

    • start defaulting to the system libffi for at least some targets
      (e.g. linux), for which we know that almost nobody will use the
      internal copy

    No, I don't volunteer to maintain ctypes itself.

    @meadori
    Copy link
    Member

    meadori commented Jul 8, 2012

    Matthias recently updated libffi to 3.0.11 (bpo-15194). It would seem that we intend to keep a local copy of the libffi sources for now and that this issue can be closed. Does anyone see a reason to keep this open?

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jul 8, 2012

    Closing as a duplicate. The original issue is resolved: we are not distributing an old copy of libffi anymore.

    @loewis loewis mannequin closed this as completed Jul 8, 2012
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants