This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.27: two weeks left of active development

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]