This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Assuming binutils and GCC features
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 25 Jun 2014 17:13:02 +0000
- 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> <20140625165715 dot 13D212C3990 at topped-with-meat 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