This is the mail archive of the
mailing list for the glibc project.
Re: glibc 2.27: two weeks left of active development
- From: Palmer Dabbelt <palmer at sifive dot com>
- To: joseph at codesourcery dot com
- Cc: carlos at redhat dot com, ldv at altlinux dot org, libc-alpha at sourceware dot org
- Date: Mon, 18 Dec 2017 10:04:33 -0800 (PST)
- Subject: Re: glibc 2.27: two weeks left of active development
- Authentication-results: sourceware.org; auth=none
On Mon, 18 Dec 2017 09:58:16 PST (-0800), firstname.lastname@example.org wrote:
On Mon, 18 Dec 2017, Carlos O'Donell wrote:
By submitting it for 2.27 you have the following consequences:
* You need to convince maintainers for review during a precious period
of time when we're preparing the release and handling bugs.
That's basically why postponing submission until the actual freeze period
would be a bad idea. If you think a port is ready for 2.27 and want it in
2.27, you should really be submitting it in the next few days so review
can start before the freeze. And the submission should have all the
information needed, such as results from full glibc test runs for each
supported ABI or other relevant configuration (using upstream GCC and
binutils, with versions used specified) and confirmation that compilation
test results for all the build-many-glibcs.py configurations added are
clean (given use of suitable upstream versions of GCC / binutils / Linux
kernel). And now details of the state of static PIE support should be
provided as well (may be absent or untested, but say so explicitly if so
as that implies it needs listing on the PortStatus page as such).
We're in Linux, the first tarball release will be 4.15. We've been in GCC
since 7.1.0 and binutils since 2.28, but it'll be a bit saner to use 7.3.0 and
I'll include this in the messages.
* You need to have confidence your port is ready and you haven't made
any real ABI mistakes. Any last minute mistakes that slip through
will become permanent ABI artifacts for the port.
There are always infelicities in the ABI that mean future changes need
compat symbols for existing ports. Provided the kernel port is upstream
(and thus the kernel/userspace ABI is known and stable), which I think we
agreed is a basic requirement for getting a glibc port upstream (the
kernel port should at a minimum be in linux-next and expected to be in
Linus's tree for the next release), and provided the glibc test results
are reasonable (I've suggested < 20 architecture-specific failures, using
upstream GCC and binutils, with no failures in the compilation tests), I
don't think the ABI provides a particular reason to aim for a given
release cycle or not. Of course ABI issues need to be considered in the
review, and the port submission should explain what ABIs are supported by
the port (including details of e.g. whether hard-float and soft-float are
different ABIs, if applicable).
OK, I'll include all this.