Skip to content

Fix libffi/ctypes - wrong libffi headers when building python #1609

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

Merged
merged 4 commits into from
Jan 26, 2019

Conversation

opacam
Copy link
Member

@opacam opacam commented Jan 25, 2019

It has been reported of errors with ctypes, even when the ctypes module seems to be built fine.
@tito is one of the affected by this and he found that, in some system configuration, python could be:

compiled with the headers of the system libffi, but runs with the target libffi

That will end in an app crash...

So...this pr makes that the python build make use of our libffi headers.

This would be a third solution to add to the ones proposed by @tito in #1605

This solution avoids to patch python3 and will also work for python2

!!!So many thanks @tito to found where the problem started 😄!!!

To simplify the linkage of the libffi library (with this we will know exactly where will be built libffi files before the build happens)
Because the python3's recipe uses pkg-config to link with the libffi library, and pkg-config reads the libffi.pc file which does not have the right values for us because we never performed the install for the libffi recipe. With this, we will make sure that the libffi.pc files has the standard header values so the python build could make use of it and explicitly link with our library.
To make sure that python links explicitly with our library

Note: This should solve the ctypes error reported by some users caused because python gets built with a wrong libffi library
…quirements

This is only necessary for python2 because in python3 the configure option that we use in python2 has been removed
@ghost
Copy link

ghost commented Jan 25, 2019

👍 this looks like the more comprehensive solution that avoids unnecessary patches to the project itself. While it appears to add a little complexity, it is limited to the libffi-recipe and I personally think this approach is the better one (not to say that @tito 's solution is bad or anything)

Copy link
Member

@inclement inclement left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

@inclement inclement merged commit 2bb7285 into kivy:master Jan 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants