Repository navigation
Flaky detection of compiler vendor #83142
Description
| BPO | 38961 |
|---|
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 = None
closed_at = None
created_at = <Date 2019-12-03.16:40:39.489>
labels = ['3.8', 'build', '3.7', '3.9']
title = 'Flaky detection of compiler vendor'
updated_at = <Date 2019-12-06.22:18:24.035>
user = 'https://bugs.python.org/jmaargh'bugs.python.org fields:
activity = <Date 2019-12-06.22:18:24.035>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2019-12-03.16:40:39.489>
creator = 'jmaargh'
dependencies = []
files = []
hgrepos = []
issue_num = 38961
keywords = []
message_count = 1.0
messages = ['357755']
nosy_count = 1.0
nosy_names = ['jmaargh']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue38961'
versions = ['Python 2.7', 'Python 3.7', 'Python 3.8', 'Python 3.9']
Activity
jmaargh commentedon Dec 3, 2019
The
configurescript for building what appears to be any version of python (I've manually checked 2.7, 3.6.6, and master) uses simple substring-in-path checks to determine the compiler vendor. This is problematic because it is very easy for it to produce very confusing false-positives.This appeared for me when compiling with a custom version of
clanglocated at/home/riccardo/some/path, which caused this linecpython/configure
Line 7546 in 8943318
to mistakenly assume an ICC configuration (because
iccis a substring ofriccardo). A quick check through the script reveals that compiler vendor detection in the script doesn't appear to be unified and are mostly similarly flaky.Other projects compile a small program that checks for defines, or parses the output of
$CC --versionor similar.encukou commentedon Oct 15, 2026
This was fixed in #117815.