-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-Werror=declaration-after-statement is added even for extension modules through setup.py #65320
Comments
I got an error while rebuilding a module for 3.4. This was a ISO C90 error but setup.py explicitely adds "-std=c99" to the gcc parameters, and indeed it is used. fifo.h:114:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] However, Py 3.4 seems to add -Werror=declaration-after-statement also for extension modules. This should not happe (said also Yhg1s in #python). Attached is a file that shows the setup.py and also the error log. |
It looks like -Werror=declaration-after-statement was added to BASECFLAGS in configure.ac during the 3.4 development cycle by a3559c8c614b and e47806951fb2. Unfortunately, BASECFLAGS propagates through to extension module builds as well. If -Werror=declaration-after-statement should only be restricted to the build of the interpreter executable itself, one option *might be* to move the test and definition to CFLAGSFORSHARED in configure.ac. A workaround could be to define CFLAGS before rebuilding a module: export CFLAGS=$(python3.4 -c 'import sysconfig; print(sysconfig.get_config_var("CFLAGS").replace("-Werror=declaration-after-statement",""))') (As usual, my brain hurts after trying to sift through the myriad build flags and their interactions in configure.ac, Makefile, and setup.py.) |
The workaround indeed works. At least I can work now until this gets officialy fixed. Thanks! export CFLAGS=$(python3.4 -c 'import sysconfig; print(sysconfig.get_config_var("CFLAGS").replace("-Werror=declaration-after-statement",""))') |
Here is a patch. I do not see a really nice way to deal with the problem. |
I ran into this issue right after 3.4 got released. I solved it by adding extra_compile_args=["-Wno-error=declaration-after-statement"] as an argument to the Extension() call in the package's setup.py . |
Stefan, the patch LGTM although I sure wish we were removing some CFLAGS-related configuration variables rather than adding another. But I don't have a better suggestion short of a comprehensive cleanup of all of them. |
Thanks, Ned. I'm attaching a second version of the existing patch The result is slightly overcomplicated, so I came up with a |
I like bpo-21121-3.diff. |
I agree: bpo-21121-3.diff is a much better approach. |
If you guys want this in 3.4.1, please get it checked in in the next, oh, eight hours. |
I can't commit today. Perhaps one of you wants to take over (I think we all |
Sorry, I should have said "3.4.1rc1". You can still get it in for 3.4.1. |
I can commit the patch but won’t be able to check the buildbots for the next twelve hours. |
There's no immediate rush now. It's too late for 3.4.1rc1. |
One more question: I think it's nicer to add CFLAGS_NODIST to 'renamed_variables' in renamed_variables = ('CFLAGS', 'CFLAGS_NODIST', 'LDFLAGS', 'CPPFLAGS') That way it's possible to look up CFLAGS_NODIST directly. For consistency, we can do the same for Lib/distutils/sysconfig.py, |
Is there any reason to expose CFLAGS_NODIST externally? It seems to me that it is only needed in the top-level setup.py for building standard library extension modules. Let's not add yet another configuration variable to the already confusing array we present to users through the two sysconfig.get_config_var(). |
The current patch allows the user to specify e.g.: CFLAGS_NODIST="-march=core2" ./configure So it would be surprising to get: >>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS_NODIST')
'' Now, we could restrict ourselves entirely to internal PY_CFLAGS_NODIST, |
I don't have a *really* strong opinion against it. It's just that I find the current plethora of configuration flags to be non-intuitive and confusing (and there are plenty of open issues agreeing with that sentiment) and adding another with the name CFLAGS_NODIST doesn't help. But, again, short of someone going in and doing a radical simplification of the whole configure.ac, Makefile.pre.in, and setup.py tangle, I guess exposing one more variable isn't going to make matters that much worse than they already are and it does solve a real problem. (Sorry to vent on your patch, Stefan.) |
I share Ned's sentiment on this. The amount of information exposed through sysconfig is too large as it is because a lot of that information is only useful during the built of python itself. I'm pretty sure that have been patches in the past where users tried to use some of those variables and were surprised they didn't work for an installed python. Anyways, the patch looks good. |
This patch should definitely go in. |
New changeset 2a3538f14948 by Benjamin Peterson in branch '3.4': New changeset a5368cfbea0e by Benjamin Peterson in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: