Re: Assuming binutils and GCC features

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 25 Jun 2014, Roland McGrath wrote:

> 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

There are tests for things like __thread support that would definitely 
break the build if missing.  Now, breakage at configure time with a 
meaningful error is better than breakage later in the build - but the 
check for minimum binutils and GCC versions should be sufficient to ensure 
configure gives an error for most missing features.

> 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.)

Well, in the relro case it was apparently 
<https://sourceware.org/ml/libc-hacker/2004-09/msg00069.html> (the option 
not doing anything useful in certain cases, rather than breaking things).  
But

commit 2e6ab1df44c412bb9d30b26a4d8a679150a7e375
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Sat Oct 28 06:44:04 2006 +0000

    Remove conditional code which now is unnecessary.

(commit reference from git://repo.or.cz/glibc/history) made the -z relro 
use unconditional, so I'm doubtful of the use of the configure test at any 
point since then.

> 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.

The binutils version requirement has been bumped up a lot since that 
configure check and probably most of the others - we require 2.20 
(released Oct 2009) or later.  Now, I think we could reasonably require 
probably 2.22 or later, and GCC 4.6 or later - but even with our present 
minimum requirements, I think many of the checks are long-obsolete.

-- 
Joseph S. Myers
joseph@codesourcery.com