glibc 2.27: two weeks left of active development

[Palmer Dabbelt]

On Mon, 18 Dec 2017 09:58:16 PST (-0800), joseph@codesourcery.com 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 
2.30.

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.