This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: Merge MIPS libc-abis into top-level
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 28 Oct 2014 21:32:14 +0000
- Subject: RE: Merge MIPS libc-abis into top-level
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320F188C6 at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1410191543480 dot 15206 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B0235320F3064C at LEMAIL01 dot le dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1410242137320 dot 9806 at digraph dot polyomino dot org dot uk>
Joseph S. Myers <joseph@codesourcery.com> writes:
> On Wed, 22 Oct 2014, Matthew Fortune wrote:
>
> > From an arch perspective I don't think it is acceptable for anyone to
> > introduce a new libc-abi that claims to be arch-independent without
> > explicitly getting approval from every arch maintainer as a new value
> > will be required. It seems appropriate to have to update a file in
> > each sysdeps folder to get that approval. With that in mind I suggest
> > copying the libc-abis to every arch folder and removing the top level
> > file.
>
> Anything involing getting approval from each architecture maintainer seems
> like something to be avoided if possible as causing long bottlenecks
> (months) on changes.
I generally agree but in this case not getting approval for an ABI increase
seems wrong.
> If you don't do the timestamp-based merging, then the implication is that
> any new architecture-independent abiversion needs adding to files for each
> architecture with some architecture-specific abiversion - but I don't see
> any point in duplicating copies of the file with no architecture-specific
> abiversions. That is, my suggestion (if we don't do timestamp-based
> merging) would be:
>
> * Each architecture with IFUNC support gets a copy of the file, mentioning
> both UNIQUE and IFUNC, but with abbreviated comments like in the MIPS file
> rather than the full ones present in the top-level file.
>
> * The top-level file only has UNIQUE.
>
> * Once that is done, the PLATFORM column should be removed from the files
> and all code processing it removed (so that exactly one such file is found
> through sysdeps, and that file always processed).
>
> * Add files mentioning both UNIQUE and IFUNC for S/390, AArch64 and ARM.
>
> * Anyone adding new architecture-independent features to binutils in
> future that require abiversion settings because of incompatibility with
> older dynamic linkers has the responsibility to ensure the value depends
> correctly on the architecture.
I think your suggestion is sufficient to cover the likely needs of
libc-abis. Since this only affects the glibc build system and internals
then it can always be made more elaborate when faced with some complex
scenario.
Unless you have an objection I'm happy to re-post your suggestion on a new
thread to get consensus.
Matthew