This is the mail archive of the
mailing list for the glibc project.
RE: [RFC] Remove platform dependent information from top-level libc-abis
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 13 Nov 2014 12:26:54 -0800 (PST)
- Subject: RE: [RFC] Remove platform dependent information from top-level libc-abis
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F69E2B at LEMAIL01 dot le dot imgtec dot org> <6D39441BF12EF246A7ABCE6654B0235320F6F055 at LEMAIL01 dot le dot imgtec dot org> <20141112233538 dot 6D6DD2C3B32 at topped-with-meat dot com> <6D39441BF12EF246A7ABCE6654B0235320F6F325 at LEMAIL01 dot le dot imgtec dot org>
> I'm not sure that there is any real danger in machine dependent libc-abis
> not being updated and there may be a justifiable reason why some ports
> adopt the feature after others. I.e. if binutils also grows a framework
> for generic ABIVERSIONs vs machine dependent then it is reasonable that
> the generic version would get updated first and each arch (that has taken
> control of its ABIVERSIONs) can then update at their discretion.
The scenario that concerns me is a generic new feature being added to
binutils and to machine-independent libc code, while some libc machine
maintainers fail to notice entirely. (Sometimes the machine maintainer is
the same person for binutils and libc or they are in close collaboration,
but not always.)
> I was thinking that a carefully phrased comment in the top level libc-abis
> would be sufficient to make people consider the arch specific libc-abis.
People ignore comments. Reviewers fail to notice relevant past comments.
Actual red flags that cannot easily be overlooked are much better.
> A more complex solution would require checking that all values in the top
> level libc-abi are present in the sysdeps libc-abi (or perhaps recorded as
> explicitly not yet supported). The problem here is that you have to build
> every port to run the check so it may not add much value.
That's the sort of thing I had in mind. It's fine if the problem on a
given machine isn't noticed until someone builds for that machine. It adds
just as much value as every other test we have. Machine maintainers run
all the tests before we make a release, so they will notice the failure then.