Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #76685 > unrolled thread

Re: Test failure while building cpython

Started byNed Deily <nad@acm.org>
First post2014-08-20 17:25 -0700
Last post2014-08-20 17:25 -0700
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Test failure while building cpython Ned Deily <nad@acm.org> - 2014-08-20 17:25 -0700

#76685 — Re: Test failure while building cpython

FromNed Deily <nad@acm.org>
Date2014-08-20 17:25 -0700
SubjectRe: Test failure while building cpython
Message-ID<mailman.13223.1408580714.18130.python-list@python.org>
In article <09843563-B0FD-451B-BF66-0FB720CEC67A@ja.net>,
 Adam Bishop <Adam.Bishop@ja.net> wrote:
> I'm trying to build python 3.3.2 from source packages provided by Red Hat 
> under mock.
> 
> The build itself works,but one specific test is failing:
>   
>    ======================================================================
>    FAIL: test_sysconfig_module 
>    (distutils.tests.test_sysconfig.SysconfigTestCase)
>    ----------------------------------------------------------------------
>    Traceback (most recent call last):
>      File 
>      "/builddir/build/BUILD/Python-3.3.2/Lib/distutils/tests/test_sysconfig.py
>      ", line 134, in test_sysconfig_module
>        self.assertEqual(global_sysconfig.get_config_var('CFLAGS'), 
>        sysconfig.get_config_var('CFLAGS'))
>    AssertionError: '-Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -g 
>    -pipe -Wall -Wp,-D_FO [truncated]... != '-Wno-unused-result 
>    -DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -g -pipe -Wall -Wp,-D_FO 
>    [truncated]...
>    - -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -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 -I/usr/include-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  -I/usr/include-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   -O1
>    ?                                                                          
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                     
>    ---------------------------------------------------------------------------
>    ---------------------------------------------------------------------------
>    --------------------------------------------------
>    + -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -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 -I/usr/include-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
>    
>    
>    ----------------------------------------------------------------------
>    Ran 189 tests in 1.778s
> 
> Obviously I could simply disable the test[1], but this requires patching the 
> source package, which I'd rather avoid because I don't fully understand what 
> case this test is trying to detect.
> 
> Is anyone able to indicate what the test is looking for and what might cause 
> it to fail? I don't see how the CFLAGS used in the build process could change 
> during the test run.

The test is to check that the two separate implementations of sysconfig 
in the standard library (don't ask why!), the newer sysconfig and the 
legacy distutils.sysconfig, return the same results for certain key 
configuration variables, like CFLAGS.  It's not the most critical test 
in the world.  The important point is that the values from the 
distutils.sysconfig version are what will be used during C extension 
module builds when you install third-party packages and, if necessary, 
most of them can be overridden, either in the package's setup.py or by 
setting environment variables.  Also, be aware that Python 3.3.2 is 
obsolete.

-- 
 Ned Deily,
 nad@acm.org

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web