This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Assuming binutils and GCC features

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]