homepage

--with-system-ffi is mandatory for linux build but no way is provided ( eg --with-ffi-includes= --with-ffi-libs= ) so setup.py can detect libffi already built in $PREFIX and $EPREFIX/lib.
even if cflags/ldflags are ok , _ctypes build will be skipped with reason:
INFO: Could not locate ffi libs and/or headers
test condition: crystax-ndk toward android-19 on ubuntu xenial 32 bits

> even if cflags/ldflags are ok 
Might be this. setup.py doesn't use -I flags in $CFLAGS. It looks into $CPPFLAGS only.

Also happens on suse 11 x86_64 with python 3.7
Same issue exactly building locally (but with cross compiling flag for system independency)
Building our own libffi 3.2.1 and adding it in the CPPFLAGS includes.

Hi Roy, mind sharing the complete build log? Either attaching the log to this issue or pasting a link is fine.

Sure, I'll attach it. one more thing to mention is that during configure it printed: configure: WARNING: --with(out)-system-ffi is ignored on this platform
We are also providing all the dependency libraries ourselves (building, linking, h files and what not) so that should tkae into consideration.
on Suse 11 x86 build is working fine.
and we are using gcc 4.3.4
configure arguments passed:
--prefix=/root/rc3/dist --enable-shared --enable-ipv6 --with-dbmliborder=gdbm --with-gcc --with-system-ffi --with-openssl=/root/rc3/dist

A possible case might be that pkg-config on your build machine is not properly configured. Could you check the value of LIBFFI_INCLUDEDIR in config.log? It shuold either be an empty string or /root/rc3/dist/lib/libffi-3.2.1/include.
As a reference, the following command is used to compute LIBFFI_INCLUDEDIR: https://github.com/python/cpython/blob/v3.7.0/configure.ac#L2936 

as seen in the config.log:
LIBFFI_INCLUDEDIR='/root/rc3/dist/lib/libffi-3.2.1/include'
I'm attaching the config.log just in case

Thanks for providing the info. However, I'm sorry as the case is beyond my knowledge. Here's the relevant section in CPython that handles LIBFFI path searching: https://github.com/python/cpython/blob/v3.7.0/setup.py#L1984-L2002. You may want to examine variables there to see if there's something unusual.

Also ran into this issue while building Python in an isolated environment. Realized that libffi is installing into the $EPREFIX/lib64 directory of our build environment.
Despite pkg-config returning the correct directory for linking libffi, it took explicitly setting LDFLAGS to the correct lib64 directory in my build process for the Python build to succeed.
I noticed from your build.log that you don't explicitly add your lib64 to your LDFLAGS. Perhaps give that a shot?

Was having the same issue compiling python 3.7.1 against locally compilied libffi 3.2.1. 
Setting CPPFLAGS and LDFLAGS was not enough and was still getting the same error: INFO: Could not locate ffi libs and/or headers
Everything worked as soon as i added PKG_CONFIG_PATH to point to the location of the directory that had libffi.pc
For me that was /foo/bar/distrib/libffi-3.2.1/x86_64-unknown-linux-gnu 
Can test if it works with this:
pkg-config libffi --cflags-only-I

I had also received the same warnings when running make:
"INFO: Could not locate ffi libs and/or headers"
and "Failed to build these modules: _ctypes". Although Python could still be installed, the pip command was not installed, and installing it using get_pip.py just led to an error indicating that the module "_ctypes" was not found.
I can confirm that setting CPPFLAGS and LDFLAGS as well as PKG_CONFIG_PATH, as suggested my Mr. Levchenko, allowed me to build and install python 3.7.1 locally without root privileges with ctypes and pip included and working, using a libffi also compiled from source.

Thanks for the report and for the analysis. There have been a number of reports over the years about problems trying to build and/or execute Pythons with an external copy of libffi. They have become more pressing now that we no longer vendor the source of libffi in Python source releases. To help focus on the issues, we are consolidated the discussion in Issue14527, one of the earliest opened issues.