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 doko
Recipients Arfrever, benjamin.peterson, brian.curtin, doko, georg.brandl, jcea, loewis, meador.inge, nadeem.vawda, pitrou, rosslagerwall, rpetrov
Date 2012-04-17.11:18:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1334661506.9.0.930186365793.issue12081@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-04-17 11:18:27dokosetrecipients: + doko, loewis, georg.brandl, jcea, pitrou, nadeem.vawda, benjamin.peterson, rpetrov, Arfrever, brian.curtin, meador.inge, rosslagerwall
2012-04-17 11:18:26dokosetmessageid: <1334661506.9.0.930186365793.issue12081@psf.upfronthosting.co.za>
2012-04-17 11:18:26dokolinkissue12081 messages
2012-04-17 11:18:26dokocreate