Title: python-config --cflags includes irrelevant flags
Type: behavior Stage:
Components: Build Versions: Python 3.2, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: doko Nosy List: Joe.Neeman, Matthias.Braun, doko, erickt, georg.brandl, loewis, sacha
Priority: normal Keywords: patch

Created on 2008-07-05 19:09 by sacha, last changed 2013-03-28 13:09 by terry.reedy.

File name Uploaded Description Edit
python-config-filter-cflags.patch Matthias.Braun, 2013-03-05 00:20 review
Messages (11)
msg69289 - (view) Author: Sacha Varma (sacha) Date: 2008-07-05 19:09
As I understand it, python-config --cflags is intended to yield the C
compiler flags needed to compile a program that uses Python headers and
libraries (as opposed to the C flags needed to compile python itself).

However, it seems to include irrelevant options such as -Wall and -O3,
which interfere with the build (for example, by enabling optimisation in
a debug build):

$ python-config --cflags
-I/opt/Python-2.5.1/include/python2.5 -fno-strict-aliasing
-Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall
msg69292 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-07-05 20:10
Georg, what do you think?
msg69317 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-07-06 06:19
I think you're right.

However, Martin, what flags except -I can/must we keep?
msg69320 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-07-06 06:43
Some flags for the compiler are really needed to compile the Python
headers correctly, e.g. -fno-strict-aliasing in 2.6.

So I think an explicit list of options reported would have to be
maintained, either as a blacklist (e.g. -O<n>, -Wall), or as a white list.
msg73878 - (view) Author: Erick Tryzelaar (erickt) Date: 2008-09-26 18:59
fyi, on the mac with gcc-4.2, distutils is erroring out because of the "-
Wno-long-double" it is getting from "python-config --cflags", as it's no 
longer accepted as an argument. Fortunately this can be worked around by 
doing "CC=gcc-4.0 python".
msg107977 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-06-17 01:11
Is this still an issue for current trunks?
msg110148 - (view) Author: Joe Neeman (Joe.Neeman) Date: 2010-07-12 23:35
It's still an issue in Python 2.6.5 as packaged by openSUSE 11.2.
msg183506 - (view) Author: Matthias Braun (Matthias.Braun) Date: 2013-03-05 00:20
I hacked up a proof-of-concept patch which filters out the most annoying flags (warnings, -Ox and -DNDEBUG flags).

(Though IMO the only really robust solution would be not having code but just declarations in the public headers, so --includes is enough. In my personal project I ended up to just use --includes and manually make sure that I don't use any of the code in the headers, but just the declarations).
msg185435 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-03-28 11:31
I don't see the current behaviour as problematic. If you build python as a debug build, you get the -O0 included, if you do a normal build, you get the -Ox included.  At least this is behaviour found in other '-config' programs too.  So maybe add an option to filter out flags, but which ones?

The other issue is that it's unclear what these options are used for, to build an extension module, or to build an embedded interpreter. Not a difference maybe in cflags, but for ldflags. And this should be harmonized with the pkgconfig file too.
msg185436 - (view) Author: Matthias Braun (Matthias.Braun) Date: 2013-03-28 11:44
It's less of a problem when building python extenions, where you are probably fine with using "just the same" as the installed python.

However in my case I am embedding python as a scripting language into another application. So there is very few python related code and alot of other code. The python-config script "injecting" unnecessary build flags that in fact even change things (-DNDEBUG) is very annoying as it changes all the non-python code too.

A simple thing like the --includes that just outputs the -I flags would be the best solution IMO. But to have this working you would need to have a guarantee that there is no actual code in the form of #define / inline functions in the headers which potentially breaks if you use different flags from the python library. In fact --includes is what I am using now, I just hope that I won't hit any of the preproc macros by accident...
msg185437 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2013-03-28 11:48
> However in my case I am embedding python as a scripting language
> into another application.

then why not filtering out these options on your own for this use case?
Date User Action Args
2013-03-28 13:09:59terry.reedysetnosy: - terry.reedy
2013-03-28 11:48:18dokosetmessages: + msg185437
2013-03-28 11:44:22Matthias.Braunsetmessages: + msg185436
2013-03-28 11:31:34dokosetmessages: + msg185435
2013-03-28 10:06:08georg.brandlsetassignee: georg.brandl -> doko

nosy: + doko
2013-03-05 00:20:37Matthias.Braunsetfiles: + python-config-filter-cflags.patch

nosy: + Matthias.Braun
messages: + msg183506

keywords: + patch
2010-07-12 23:35:36Joe.Neemansetnosy: + Joe.Neeman
messages: + msg110148
2010-06-17 01:11:56terry.reedysetnosy: + terry.reedy

messages: + msg107977
versions: + Python 2.7, Python 3.2, - Python 2.5
2008-09-26 18:59:43ericktsetnosy: + erickt
messages: + msg73878
2008-07-06 06:43:32loewissetmessages: + msg69320
2008-07-06 06:19:02georg.brandlsetmessages: + msg69317
2008-07-05 20:10:50loewissetassignee: georg.brandl
messages: + msg69292
nosy: + loewis, georg.brandl
2008-07-05 19:09:06sachacreate