This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [RFC] Remove platform dependent information from top-level libc-abis
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 13 Nov 2014 10:03:51 +0000
- 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>
> I think it does make sense to consider these values as machine-dependent.
> However, I also want to make sure that we do something to prevent the
> danger of new machine-independent features being added but some machines
> with their own libc-abis files failing to update.
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.
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.
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.
Matthew