Skip to content
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.

Sign up for GitHub

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

Jump to bottom

-Werror=statement-after-declaration problem #62411

Closed
ronaldoussoren opened this issue Jun 14, 2013 · 11 comments
Closed

-Werror=statement-after-declaration problem #62411

ronaldoussoren opened this issue Jun 14, 2013 · 11 comments
Assignees
@merwok
Labels
build The build process and cross-build stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ronaldoussoren
Copy link
Contributor

BPO 18211
Nosy @ronaldoussoren, @vstinner, @tiran, @benjaminp, @tarekziade, @jkloth, @merwok
Superseder
  • bpo-21121: -Werror=declaration-after-statement is added even for extension modules through setup.py
    		•
    Files
  • issue18211-hack.txt
  • issue18211-hack-v2.txt
    		•

    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:

    assignee = 'https://github.com/merwok'
closed_at = <Date 2014-05-04.18:08:47.707>
created_at = <Date 2013-06-14.11:50:35.794>
labels = ['type-bug', 'library', 'build']
title = '-Werror=statement-after-declaration problem'
updated_at = <Date 2014-05-04.18:08:47.706>
user = 'https://github.com/ronaldoussoren'

    bugs.python.org fields:

    activity = <Date 2014-05-04.18:08:47.706>
actor = 'eric.araujo'
assignee = 'eric.araujo'
closed = True
closed_date = <Date 2014-05-04.18:08:47.707>
closer = 'eric.araujo'
components = ['Build', 'Distutils']
creation = <Date 2013-06-14.11:50:35.794>
creator = 'ronaldoussoren'
dependencies = []
files = ['30638', '30639']
hgrepos = []
issue_num = 18211
keywords = []
message_count = 11.0
messages = ['191119', '191311', '191404', '191405', '191407', '191415', '193158', '193182', '193607', '217872', '217873']
nosy_count = 8.0
nosy_names = ['ronaldoussoren', 'vstinner', 'christian.heimes', 'benjamin.peterson', 'tarek', 'jkloth', 'eric.araujo', 'Arfrever']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '21121'
type = 'behavior'
url = 'https://bugs.python.org/issue18211'
versions = ['Python 3.4']
    @ronaldoussoren
    Copy link
    Contributor Author

    Changeset a3559c8c614b added -Werror=statement-after-declaration to the CFLAGS for compiler that support it.

    This new flags is fine for CPython itself (which is explicitly writting in C89 style to support older compilers and Microsoft Visual Studio), but the new flags also gets used when building 3th-party extensions using distutils and might cause problems there when that code uses C99.

    I don't have a good solution for this yet, the flag is useful to have when building CPython to avoid regressions in C89 support but shouldn't be used when building 3th-party extensions.

    @ronaldoussoren ronaldoussoren added build The build process and cross-build stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Jun 14, 2013
    @benjaminp
    Copy link
    Contributor

    Yes, we definitely need some way for CPython compiler flags to not infect everything built with distutils.

    @ronaldoussoren
    Copy link
    Contributor Author

    Is "-Werror=statement-after-declaration" the right solution anyway? This errors out on just one of the incompatibilities between C89 and C99, although it is one that is easy to get wrong accidentally.

    Gcc (and clang) also support '-std=c89' that forces the compiler to support only that standard. Not that switching to that flag would get us closer to closing this issue :-)

    BTW. To make things more fun: both sysconfig and distutils.sysconfig contain code to parse the Makefile, and those two sets of code are not equivalent (distutils.sysconfig lets you override values using the environment, sysconfig does not).

    The attached crude hack fixes this particular issue, but I'm far from convinced that is is the right solution for two reasons: first of all it is a hack, second of all it drops the -Werror flag when building CPython's extensions.

    A better solution would be the introduction of a new variable in the Makefile that contains those CFLAGS that should only be used during the build of Python itself, all those flags can then be ignored by the Makefile parsers in distutils.sysconfig and sysconfig. The disadvantage is that is introduces even more complexity in the Makefile.

    @ronaldoussoren
    Copy link
    Contributor Author

    I had a patch that only changed distutils.sysconfig.get_config_var('CFLAGS') when not building python, but then noticed that this doesn't work: the setup.py file for stdlib extensions fetches information from the toplevel sysconfig file, not distutils.sysconfig and uses that to override some information (look for "make CC=altcc").

    There are two problems there, for which I'll file separate issues:

    1. setup.py shouldn't use sysconfig but distutils.sysconfig

    2. the block of code that I mentioned earlier is not necessary at all, the comment is plain wrong (tested by removing the compiler update and running 'make CC=no-such-file')

    V2 of the hack triggers the change of BASECFLAGS only when not building the stdlib, but that doesn't work right now because of the issues mentioned earlier.

    @ronaldoussoren
    Copy link
    Contributor Author

    The setup.py issues are in bpo-18255.

    @ronaldoussoren
    Copy link
    Contributor Author

    I just noticed the patch is not good enough: "python-config --cflags" still prints the -Werror flag because it is now a shell script and doesn't use sysconfig data at all.

    @vstinner
    Copy link
    Member

    By the way, I don't think that Python should pass the optimization level (-O0 or -O3) to extensions, except for builtin extensions (of the stdlib).

    @benjaminp
    Copy link
    Contributor

    Why not?

    @ronaldoussoren
    Copy link
    Contributor Author

    I also don't understand why the optimization level shouldn't be used when building 3th-party extensions.

    Removing the -O flag for build_ext would be a regression compared to the current behavior because 3th-party extensions would suddenly be compiled with less optimization than before and extension authors would have to arrange for those flags themselves. That's fine on platforms using a compiler with a command-line interface that's simular to GCC, but the are compilers that don't (such as a number of vendor compilers for the various commercial unix systems).

    @ronaldoussoren
    Copy link
    Contributor Author

    Closing this one because bpo-21121 contains a usable patch.

    @ronaldoussoren
    Copy link
    Contributor Author

    Sigh. Actually closing doesn't work due to the dependency :-(

    @merwok merwok closed this as completed May 4, 2014
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @merwok merwok

    Labels
    build The build process and cross-build stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    4 participants
    @vstinner @benjaminp @merwok @ronaldoussoren