This is the mail archive of the
mailing list for the glibc project.
Re: Use gen-libm-test.py to generate ulps table for manual
On Mon, 13 Aug 2018, Andreas Schwab wrote:
> On Aug 09 2018, Joseph Myers <firstname.lastname@example.org> wrote:
> > patch.) Note that this introduces a Python dependency for building
> > the manual, which is thus noted in install.texi and NEWS.
> This would add python to the bootstrap cycle which is a big problem.
Why is it a big problem? I'd expect it to be at most a one-off addition
to an automated bootstrap process.
(a) If you are bootstrapping purely from sources and a minimum set of
binaries (e.g. starting from GNU Mes), e.g. to defend against Thompson
attacks, you'll inevitably need various techniques to break cycles. In
this case it's very simple: an early glibc build might not build the
manual (or run tests, etc.), but once Python has been built a full glibc
build can build the manual and run tests. Even with Python required for
the build, such a bootstrap from a minimum set of binaries would probably
in practice need to start with building older, simpler versions of various
tools with reduced dependencies (GNU Mes does).
(b) If you are bootstrapping a new architecture by cross-compilation, (i)
Python on the build system is fully sufficient for building the
cross-compiled glibc including its manual, and (ii) either you can
cross-compile Python, or you can build it natively later.
(c) If you are repeatedly rebuilding packages with themselves - in the
full configuration building everything from those packages intended to be
in a release - to ensure the rebuilds converge to a set of binary packages
that are byte-for-byte reproducible when rebuilt with themselves (a
stronger version of reproducible builds than the ones where reproducibly
building package X in a release depends on having an older version of
package Y than the one included in that release), it doesn't even affect
the set of packages that depend on each other because Python is already
used in glibc testing.
For both (a) and (b), having automation of the bootstrap process is
clearly strongly desirable, and maybe a one-off change to that automation
would be needed to insert a few extra builds. For (c) I'd expect existing
automation to be able to work automatically with the build-dependencies so
only those need updating for it to determine the updated set of packages
to rebuild (and as noted, Python is already a dependency for running the
full set of tests).
There was clear support in the discussion descending from
<https://sourceware.org/ml/libc-alpha/2018-07/msg00549.html> for replacing
both perl and awk code in the build with python for the reasons described
at <https://sourceware.org/ml/libc-alpha/2018-07/msg00559.html>: it's now
better for the current community maintaining glibc. For the bootstrap
cases discussed, I don't think Python is significantly different from any
other widely-available build dependency - glibc is very careful about
cyclic build dependencies in the actual cross-toolchain bootstrap for (b)
(glibc built with a static-libgcc-only C-only GCC should be identical to
one built in a cycle iterated more times, although you need to rebuild
glibc with the shared-libgcc C++-supporting GCC to get a build tree
appropriately configured to run the tests), but for tools that only need
to be present on the build system to build glibc (not to be built
specially for the glibc architecture), and where there aren't strong
dependencies on particular versions, I think such bootstrap considerations
are really matters for other projects not for glibc.
Joseph S. Myers