homepage

1) Checkout a 3.4 tree. Mine was at revision d244e1770f1b.
2) ./configure
3) make -j14 profile-opt
4) ./python -m test.regrtest -v test_distutils
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/.../oss/cpython/3.4/Lib/distutils/tests/test_sysconfig.py", line 131, in test_sysconfig_module
 sysconfig.get_config_var('CFLAGS'))
AssertionError: '-Wno[38 chars] -Wall -Wstrict-prototypes -fprofile-use -fprofile-correction' != '-Wno[38 chars] -Wall -Wstrict-prototypes'
This can be traced to the built _sysconfigdata.py file which contains the command line passed CFLAGS from the build_all_use_profile target's sub-make vs the distutils.sysconfig module's Makefile parsing which finds the PY_CFLAGS value from the Makefile itself.
One of either stripping the profile-opt related flags out when generating _sysconfigdata.py or explicitly generating a good _sysconfigdata.py file outside of the sub-make's with the profiling generate or use flags seems like a good idea. The latter is likely easier; just regenerate _sysconfigdata.py after the sub-make.

Should _sysconfigdata.py contain these flags for reference, implying that it is this test or distutils.sysconfig implementation which is really wrong?

attaching a proposed workaround in the unittest.

see also issue23390 

I'm also hitting an issue with test_sysconfig_module, but for a different reason: While building Python, I used "make EXTRA_CFLAGS='some flags'" and this makes test_sysconfig_module fail when I run "make test" or "python -m test.regrtest".
The problem is that EXTRA_CFLAGS, like profile-opt, is not in the Makefile, so _sysconfigdata has it stored from build - unlike distutils, which can't see the EXTRA_CFLAGS variable in the environment, thus resulting in failure.
I'm not sure what's the proper solution here, but I think requiring people to run "make test" with precisely the same EXTRA_CFLAGS as "make" is not right (although it solves the issue). This makes me think this is a bug - should I open a new issue?

Slavek, this issue and its superseder are both closed so comments here will likely not be acted on.