This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Assuming binutils and GCC features
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 25 Jun 2014 09:57:15 -0700 (PDT)
- Subject: Re: Assuming binutils and GCC features
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1406251615440 dot 12113 at digraph dot polyomino dot org dot uk>
The thing to be concerned about is if the checks are catching binutils
versions that supposedly support the particular feature but in fact have
bugs that break its use in building libc. This concern lessens with the
youth of the oldest binutils that we require by the version-number check.
I'm not really sure how best to figure out if there were known bugs being
caught at the time each configure check was added (or last materially
changed). I suppose it's not too much of a concern if the bugs prevented
building libc, or broke a 'make check' test. People building with such a
binutils would notice the problem before they tried to deploy it. The ones
to be scared of are ones that do something bad we don't (or can't) test
for. I would hope that if we became aware of a bug, we'd add a test to
catch it. But we can't redress past failures to take note of bugs or write
tests if we don't know their details. (I'm not sure what kinds of bugs
there might be that we couldn't write a test for. That might be a purely
hypothetical concern.)
So I don't really have an answer, except that I'm vaguely nervous about it
but I don't think that's very rational and also think I'd be less nervous
if we also just bumped up the version requirement. I suppose we could take
each case one by one and hope that someone reviewing the removal of a check
might remember (or find a way to discover) why it was there.