This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't check ABI for _nl_default_dirname
On Sat, Dec 8, 2012 at 3:57 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> Does that make sense?
>
> Not for _nl_default_dirname at least. The whole concept of an API
> that depends on the prefix is obviously broken.
I disagree. There are all sorts of inputs to the library build that
can change the ABI and for valid reasons. The fragile testsuite is
the core problem.
> As far as I can tell noone should rely on that array size anyways, it's simply
> a bug in the ABI checker that it checks it. I provided a reasonable
> solution and you want a overengineered pony instead.
Why shouldn't someone, the implementation in particular, want to
rely on that array being the correct size? I don't see it as a bug,
and you haven't provided a detailed rationale for rejecting parts
of the ABI that vary by configuration options.
> The part that also seems wrong to me is that you guys don't seem
> to care whether your test suite is reliable or not. It's great
> that glibc has a test suite, but any borken test in the test suite
> makes it far less useful and less trustworthy. The highest priority
> for any of these is to disable them, so that people can get the test
> coverage for the non broken tests.
We care a great deal, we care so much in fact that without good
rationale we're unwilling to *remove* a symbol from the ABI testsuite
(since it works for everyone else who is using similar inputs).
The ABI in question varies with the input build options, and
IMO that's an acceptable situation. There are going to be input
options now, and in the future, that change the library ABI.
I'm suggesting we move towards a smarter checker.
> Any value that this test may have is far outweighted by the developer
> productivity damage of a fragile test suite.
I disagree with that conclusion, but I do agree that there is
productivity damage.
> Of course since this check checks the whole ABI that's not a good idea
> to disable it completely, but just disable for the symbol where it's broken
> is imho a reaonable strategy.
>
> The test suite already needs various undocumented magic incarnations
> to work (copy libstdc++ and libgcc). If I had to provide manual
> overrides for symbols like this it would be even worse and I have
> no idea how some newbie developer would ever learn to do that.
> (and no the fix is not to write more docs, the fix is to make check
> reliable by itself)
These are also areas where we need improvement, the path passed to
prefix requires a minimal set of libraries, and we should be doing
some checking for that. Please file a bug.
> It's even worse than with gcc which also has a unreliable test suite,
> but at least you're expected there to use -k and check it manually.
> But with glibc it would nearly work to trust it, except for that
> single broken check and it doesn't have the reporting
> tools to make -k work well.
Have you filed a bug for that?
> And the suggestion to wait for 2.18 was completely impractical. I need
> a passing test suite right now, not with 2.18.
I'm sorry to hear that's the situation you find yourself in, and
you have the right to patch the source.
It is true that you will need to carry a private patch for this,
we are in the freeze for 2.17 and we haven't come to a consensus
on how to handle this issue.
> I'll keep the patch for now for my private builds.
Please make sure we have a bug filed for this since it *is* a problem
with the testsuite.
Cheers,
Carlos.