Re: Why isn't "-std=c99" (and others) not part of python3-config's output?

[Random832]

On Mon, Nov 25, 2019, at 15:13, Musbur wrote:
> 2) How does one activate the necessary CFLAGs for extension building?

the standard level required for building some extension is a property of the 
extension's source code, isn't it? I don't know if including the python headers 
requires -std=c99 or not, but almost certainly they'll work with -std=c11 and 
an extension may well require it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Why isn't "-std=c99" (and others) not part of python3-config's output?

[Musbur]

I've successfully built and installed a copy of Python3.6.8 (replacing a 
probably buggy installation on my RHEL system, different story). Also I 
set up a virtualenv by doing "$ /usr/local/bin/python3.6dm -m venv 
/usr/local/pyenv36"


In my activated virtualenv, I try "$ pip install numpy" but it fails 
with lots of errors about something that is valid only in C99. Obviously 
numpy relies on -std=c99


(pyenv36)$ /usr/local/bin/python3.6dm-config  --cflags
-I/usr/local/include/python3.6dm -I/usr/local/include/python3.6dm  
-Wno-unused-result -Wsign-compare  -g -Og -Wall

(pyenv36)$

This surprises me, because "my" /usr/local/bin/python3.6m itself was 
built -std=c99, as seen in these sysconfig entries:


'CONFIGURE_CFLAGS_NODIST': '-std=c99 -Wextra -Wno-unused-result '
'PY_CFLAGS_NODIST': '-std=c99 -Wextra -Wno-unused-result '
'PY_CORE_CFLAGS': '-Wno-unused-result -Wsign-compare -g -Og -Wall 
-std=c99 '


I can install numpy on the system Python3, and not surprisingly, there 
is -std=c99 among tons of other CFLAGS:


$ /usr/bin/python3.6m-config --cflags
-I/usr/include/python3.6m -I/usr/include/python3.6m  -Wno-unused-result 
-Wsign-compare -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
  -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv   
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic 
-D_GNU_SOURCE -fPIC -fwrapv

$

My questions are:

1) Why does the output of /usr/local/bin/python3.6m-config --cflags 
differ from the CFLAGS in sysconfig.get_config_vars() ? I've confirmed 
that the /usr/local/bin/python3.6m binary and 
/usr/local/bin/python3.6m-config are really from the same build.


2) How does one activate the necessary CFLAGs for extension building?

3) Where do all the extra flags in the system /usr/bin/python3.6m-config 
--cflags come from?


4) Why isn't the config script installed into the /bin of a virtualenv? 
This is super annoying when building extensions on a multi-version 
system because it may lead to version mix-ups


A bit of background on this: I've written a C extension that leaks 
memory like a sieve on my production RHEL7's system python3 but neither 
on my Debian development system nor on my "self-built" Python on the 
production server. So I'd like to install the self-built Python on the 
production server, but for that I need a bunch of other packages to work 
as well, including numpy.


Thanks!
--
https://mail.python.org/mailman/listinfo/python-list