This is the mail archive of the
mailing list for the glibc project.
Moving ports architectures to libc?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Tue, 21 Jan 2014 23:18:55 +0000
- Subject: Moving ports architectures to libc?
- Authentication-results: sourceware.org; auth=none
Should we start moving ports architectures into libc (after 2.19 is
released), with a view to eliminating the arbitrary distinction between
the two sets of architectures (and reducing the number of ChangeLog files
needing updating for global changes)?
It's already the case that it's generally preferred for patches to update
all architectures if possible, with no distinction between libc and ports
architectures, and only if the updates are non-mechanical and need
architecture expertise or testing to list them on
<https://sourceware.org/glibc/wiki/PortStatus> and leave them for the
architecture maintainer. We've also already moved the bits of the powerpc
port that were in ports to libc.
I'd suggest the following for such moves:
* Moves only happen outside of release freeze time.
* The architecture maintainer does the move for their architecture and
verifies that, for at least one configuration for the given architecture,
the disassembly of the installed shared libraries is the same before and
after the move. (Thus, the port needs to build, unmodified, before the
move, which I think would exclude am33 and hppa from moving at present.
It does not need to be fully up to date with global changes - it may have
entries in <https://sourceware.org/glibc/wiki/PortStatus> - although I
certainly encourage maintainers to fix such issues either before or after
* Where the moved architecture #includes files from another ports
architecture that hasn't already moved to libc, the direction of the
#include should be changed before or as part of the move, so libc doesn't
depend on the ports add-on being enabled. Before moving any architecture
using linux-generic, the linux-generic support must be moved.
* There is no change to how the ports architectures do certain things in
separate files where libc architectures do them in files shared between
architectures. The approach used by ports architectures is the preferred
approach, and libc architectures should be moved to use that approach. A
detailed list is in
"libc architectures should be more like ports architectures", and such
changes are encouraged independent of any move of ports architectures to
* Similarly, sysdeps/unix/sysv/linux/<arch>/nptl, the location used by
ports architectures, is preferred to nptl/sysdeps/unix/sysv/linux/<arch>.
(That preference is why we've put abilist files for libc architectures in
such a directory, although existing sysdeps files for libc architectures
haven't yet been moved - again, moving the existing files would make
* In libc, the main ChangeLog file is used. The ChangeLog.<arch> files
are left in ports and not changed further, with the aim that in the end
the ports directory *only* contains old ChangeLog files. (As suggested in
<https://sourceware.org/ml/libc-alpha/2013-03/msg00608.html>, we might
also consider eliminating some or all of the other subdirectory ChangeLog
files and using the main ChangeLog for files in those subdirectories
* If we agree to move ports architectures to libc, then all future new
architectures should be added directly to libc (following all the
standards for ports architectures regarding use of sysdeps files not
shared files), unless they are being added before linux-generic has been
moved but depend on linux-generic.
* After a couple of release cycles, the architecture maintainer not having
moved their port should be considered evidence that it is unmaintained and
should be removed.
Joseph S. Myers