While compiling from sources I see in the process :

.
.
.
creating build/temp.solaris-2.10-sun4v.64bit-3.5/libffi
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking for gsed... /usr/local/bin/gsed
checking for a BSD-compatible install... /usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/Modules/_ctypes/libffi/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/Modules/_ctypes/libffi/install-sh -c -d
checking for gawk... /usr/local/bin/gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether /usr/local/bin/gmake supports nested variables... yes
checking for gcc... /opt/solarisstudio12.4/bin/cc
checking whether the C compiler works... no
configure: error: in `/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/build/temp.solaris-2.10-sun4v.64bit-3.5/libffi':
configure: error: C compiler cannot create executables
See `config.log' for more details


The reason for this error is that the build process down in the libffi directory seems to spawn its own "configure" stage wherein the CFLAGS are lost, forgotten or simply not used and therefore a trivial compile fails because of :

configure:3873: /opt/solarisstudio12.4/bin/cc  -I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  conftest.c  >&5
ld: fatal: file /opt/solarisstudio12.4/lib/compilers/crti.o: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to a.out
configure:3877: $? = 2
configure:3915: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libffi"
| #define PACKAGE_TARNAME "libffi"
| #define PACKAGE_VERSION "3.1"
| #define PACKAGE_STRING "libffi 3.1"
| #define PACKAGE_BUGREPORT "http://github.com/atgreen/libffi/issues"
| #define PACKAGE_URL ""
| #define PACKAGE "libffi"
| #define VERSION "3.1"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3920: error: in `/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/build/temp.solaris-2.10-sun4v.64bit-3.5/libffi':
configure:3922: error: C compiler cannot create executables
See `config.log' for more details


The configure process MUST use the CFLAGS that were passed to the original configure stage and reside in the Makefile.  The absence of the flag -m64 causes a 32-bit compile here and thus the compile fails.

Would you be interested in submitting a patch?  The whole ctypes package and the bundled libffi in particular are fairly unloved.

As a workaround, if you have libffi installed on your system, you can use the '--with-system-ffi' flag to Python's configure script to direct the ctypes build to use the installed libffi.

Also note that unless you specifically need ctypes (or are building for someone who might), it may not be the end of the world for ctypes to not be available; the overall build should not fail just due to a ctypes build failure.

On 05/26/2016 06:01 PM, Zachary Ware wrote:
>
> Zachary Ware added the comment:
>
> Would you be interested in submitting a patch?

Sure, of course. There are a number of problems in the Makefile(s) for a 
system not using gcc and where CFLAGS and LD_foo is pretty important. 
Certainly where the RPATH and RUNPATH in the resultant ELF output 
binaries really really matters. So yes, sure. If I can get it sorted out.

> The whole ctypes package and the bundled libffi in particular are
 > fairly unloved.

Put me in that ground also :-\

> As a workaround, if you have libffi installed on your system

I try to avoid it actually.

> you can use the '--with-system-ffi' flag to Python's configure
 > script to direct the ctypes build to use the installed libffi.

If there were such a thing as system libffi then I would give that a try 
but for now I am on my own and will need to everything from sources.

> Also note that unless you specifically need ctypes (or are
 > building for someone who might)

Well, strictly speaking, I don't.  However someone else may and I have 
to roll this out to a pile of systems eventually.  For now it is just 
internal on my build servers.

> it may not be the end of the world for ctypes to not be available;

Is there a configure option to disable them?  I should look.

> the overall build should not fail just due to a ctypes build failure.

cool ... let's hope for the best.

Dennis

On 05/26/2016 06:01 PM, Zachary Ware wrote:
>
> Zachary Ware added the comment:
>
> Would you be interested in submitting a patch?

Right now I am trying to get a clean build of libffi outside of the 
python tree and then will use the --use-system-libffi option to get 
around this mess. Of course, that sort of means that the libffi sources 
build and test clean and that, of course, is its own struggle.

see  https://sourceware.org/ml/libffi-discuss/2016/msg00024.html

and  https://sourceware.org/ml/libffi-discuss/2016/msg00025.html

I'll keep you posted on progress here.

Dennis

In the original report you mentioned a linker error caused by not using “-m64” from CFLAGS. Perhaps would it make more sense to add LDFLAGS=“-m64”, or use CC=“cc -m64” instead? There is also Issue 27490 and Issue 22981, both apparently about setting the ABI with CFLAGS.

As of Python 3.7.0, we no longer "vendor" a copy of the libffi source for Unix-y platforms so I believe this issue of passing the right flag values into cpython's libffi build is no longer relevant.