| Summary: | dev-lang/python: distutils CFLAGS are thrown away, subtly breaking all 3rd party distutils packages | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Erik Hvatum <ice.rikh> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | arfrever.fta, jlec, mjo, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=236332 https://bugs.gentoo.org/show_bug.cgi?id=831901 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Erik Hvatum
2015-05-06 15:00:55 UTC
Which missing flag is causing the segfault? (In reply to Mike Gilbert from comment #1) > Which missing flag is causing the segfault? Not the one I expected! -O2 seems to be the essential flag. With no optimization flag or -O0, the segfault occurs. It happens with gcc 4.6.3, 4.8.4, and 4.9.2, suggesting to me that it's not caused by a gcc optimizer bug that manifests when building pyFFTW. I can not get the segfault to occur with a debug Python 3.4.3 interpreter that I built from source (with its sysconfig.py file modified to have the same issue). I'm digging some more... it's possible that the segfault issue is merely exposed by the missing -O2 option, in which case the missing distutils cflags can only be said to trigger the segfault issue, not cause it. Nonetheless, I think many people would be surprised to find that distutils builds on Gentoo ignore the contents of the distutils CFLAGS config variable. It may make sense for emerge to ignore distutils CFLAGS so that Python does not need to be rebuilt in order for CFLAGS changes to make.conf to impact emerging of Python extensions, but the way this is currently implemented has the subtle and (to me) totally unexpected side effect of wiping out CFLAGS outside of the emerge context. Right; I'm pretty sure we wipe out the CFLAGS intentionally. We have been doing this for a *long* time; the patch predates my time as a Gentoo developer. Therefore, it is hard for me to say personally *why* we do this. Does anyone else on the python team have any insight here? (In reply to Mike Gilbert from comment #4) > Does anyone else on the python team have any insight here? Looks like the patch originates from here: http://bugs.python.org/issue1222585 Diffing the latest version of the python3.4 patch on that page and the Gentoo patch, the only differences appear related to support for emxccompiler and ensuring that mingw and not cygwin gcc is used on win32. The loss of CFLAGS might be a simple oversight made as the patch was updated through the years. I'm leaving a comment there about the CFLAGS lossage. There is talk of applying the patch into the official Python 3.5 tree, so this seems like a good time to bring up my issue :) Note that we've stopped applying this patch recently because of: 1. bug 831901 2. the confusion over the need for the patch (like this bug) |
