[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS

2020-05-07 Thread Ned Deily


Ned Deily  added the comment:

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.

--
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS

2016-07-12 Thread Martin Panter

Martin Panter added the comment:

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.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS

2016-05-26 Thread Dennis Clarke

Dennis Clarke added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS

2016-05-26 Thread Dennis Clarke

Dennis Clarke added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS

2016-05-26 Thread Zachary Ware

Zachary Ware added the comment:

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.

--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27133] python 3.5.1 will not compile because libffi module uses wrong CFLAGS

2016-05-26 Thread Dennis Clarke

New submission from Dennis Clarke:

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.

--
components: Build
messages: 266458
nosy: blastwave
priority: normal
severity: normal
status: open
title: python 3.5.1 will not compile because libffi module uses wrong CFLAGS
type: compile error
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com