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

Musbur musbur at posteo.org
Mon Nov 25 15:13:46 EST 2019


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!


More information about the Python-list mailing list