Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
#!/usr/bin/python3
|
|
|
|
# Build many configurations of glibc.
|
2024-01-01 18:12:26 +00:00
|
|
|
# Copyright (C) 2016-2024 Free Software Foundation, Inc.
|
2021-12-17 02:29:45 +00:00
|
|
|
# Copyright The GNU Toolchain Authors.
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
# This file is part of the GNU C Library.
|
|
|
|
#
|
|
|
|
# The GNU C Library is free software; you can redistribute it and/or
|
|
|
|
# modify it under the terms of the GNU Lesser General Public
|
|
|
|
# License as published by the Free Software Foundation; either
|
|
|
|
# version 2.1 of the License, or (at your option) any later version.
|
|
|
|
#
|
|
|
|
# The GNU C Library is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
# Lesser General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU Lesser General Public
|
|
|
|
# License along with the GNU C Library; if not, see
|
Prefer https to http for gnu.org and fsf.org URLs
Also, change sources.redhat.com to sourceware.org.
This patch was automatically generated by running the following shell
script, which uses GNU sed, and which avoids modifying files imported
from upstream:
sed -ri '
s,(http|ftp)(://(.*\.)?(gnu|fsf|sourceware)\.org($|[^.]|\.[^a-z])),https\2,g
s,(http|ftp)(://(.*\.)?)sources\.redhat\.com($|[^.]|\.[^a-z]),https\2sourceware.org\4,g
' \
$(find $(git ls-files) -prune -type f \
! -name '*.po' \
! -name 'ChangeLog*' \
! -path COPYING ! -path COPYING.LIB \
! -path manual/fdl-1.3.texi ! -path manual/lgpl-2.1.texi \
! -path manual/texinfo.tex ! -path scripts/config.guess \
! -path scripts/config.sub ! -path scripts/install-sh \
! -path scripts/mkinstalldirs ! -path scripts/move-if-change \
! -path INSTALL ! -path locale/programs/charmap-kw.h \
! -path po/libc.pot ! -path sysdeps/gnu/errlist.c \
! '(' -name configure \
-execdir test -f configure.ac -o -f configure.in ';' ')' \
! '(' -name preconfigure \
-execdir test -f preconfigure.ac ';' ')' \
-print)
and then by running 'make dist-prepare' to regenerate files built
from the altered files, and then executing the following to cleanup:
chmod a+x sysdeps/unix/sysv/linux/riscv/configure
# Omit irrelevant whitespace and comment-only changes,
# perhaps from a slightly-different Autoconf version.
git checkout -f \
sysdeps/csky/configure \
sysdeps/hppa/configure \
sysdeps/riscv/configure \
sysdeps/unix/sysv/linux/csky/configure
# Omit changes that caused a pre-commit check to fail like this:
# remote: *** error: sysdeps/powerpc/powerpc64/ppc-mcount.S: trailing lines
git checkout -f \
sysdeps/powerpc/powerpc64/ppc-mcount.S \
sysdeps/unix/sysv/linux/s390/s390-64/syscall.S
# Omit change that caused a pre-commit check to fail like this:
# remote: *** error: sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S: last line does not end in newline
git checkout -f sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S
2019-09-07 05:40:42 +00:00
|
|
|
# <https://www.gnu.org/licenses/>.
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
"""Build many configurations of glibc.
|
|
|
|
|
|
|
|
This script takes as arguments a directory name (containing a src
|
|
|
|
subdirectory with sources of the relevant toolchain components) and a
|
|
|
|
description of what to do: 'checkout', to check out sources into that
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
directory, 'bot-cycle', to run a series of checkout and build steps,
|
2016-12-01 00:09:25 +00:00
|
|
|
'bot', to run 'bot-cycle' repeatedly, 'host-libraries', to build
|
|
|
|
libraries required by the toolchain, 'compilers', to build
|
|
|
|
cross-compilers for various configurations, or 'glibcs', to build
|
|
|
|
glibc for various configurations and run the compilation parts of the
|
|
|
|
testsuite. Subsequent arguments name the versions of components to
|
|
|
|
check out (<component>-<version), for 'checkout', or, for actions
|
|
|
|
other than 'checkout' and 'bot-cycle', name configurations for which
|
|
|
|
compilers or glibc are to be built.
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
|
2020-02-29 11:44:31 +00:00
|
|
|
The 'list-compilers' command prints the name of each available
|
|
|
|
compiler configuration, without building anything. The 'list-glibcs'
|
|
|
|
command prints the name of each glibc compiler configuration, followed
|
|
|
|
by the space, followed by the name of the compiler configuration used
|
|
|
|
for building this glibc variant.
|
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""
|
|
|
|
|
|
|
|
import argparse
|
2016-11-26 00:10:24 +00:00
|
|
|
import datetime
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
import email.mime.text
|
|
|
|
import email.utils
|
2016-11-24 22:25:58 +00:00
|
|
|
import json
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
import os
|
|
|
|
import re
|
|
|
|
import shutil
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
import smtplib
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
import stat
|
|
|
|
import subprocess
|
|
|
|
import sys
|
2016-12-01 00:09:25 +00:00
|
|
|
import time
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
import urllib.request
|
|
|
|
|
2023-09-21 21:24:05 +00:00
|
|
|
# This is a list of system utilities that are expected to be available
|
|
|
|
# to this script, and, if a non-zero version is included, the minimum
|
|
|
|
# version required to work with this sccript.
|
|
|
|
def get_list_of_required_tools():
|
|
|
|
global REQUIRED_TOOLS
|
|
|
|
REQUIRED_TOOLS = {
|
|
|
|
'awk' : (get_version_awk, (0,0,0)),
|
|
|
|
'bison' : (get_version, (0,0)),
|
|
|
|
'flex' : (get_version, (0,0,0)),
|
|
|
|
'git' : (get_version, (1,8,3)),
|
|
|
|
'make' : (get_version, (4,0)),
|
|
|
|
'makeinfo' : (get_version, (0,0)),
|
|
|
|
'patch' : (get_version, (0,0,0)),
|
|
|
|
'sed' : (get_version, (0,0)),
|
|
|
|
'tar' : (get_version, (0,0,0)),
|
|
|
|
'gzip' : (get_version, (0,0)),
|
|
|
|
'bzip2' : (get_version_bzip2, (0,0,0)),
|
|
|
|
'xz' : (get_version, (0,0,0)),
|
|
|
|
}
|
|
|
|
|
2017-01-10 18:31:19 +00:00
|
|
|
try:
|
|
|
|
subprocess.run
|
|
|
|
except:
|
|
|
|
class _CompletedProcess:
|
|
|
|
def __init__(self, args, returncode, stdout=None, stderr=None):
|
|
|
|
self.args = args
|
|
|
|
self.returncode = returncode
|
|
|
|
self.stdout = stdout
|
|
|
|
self.stderr = stderr
|
|
|
|
|
|
|
|
def _run(*popenargs, input=None, timeout=None, check=False, **kwargs):
|
|
|
|
assert(timeout is None)
|
|
|
|
with subprocess.Popen(*popenargs, **kwargs) as process:
|
|
|
|
try:
|
|
|
|
stdout, stderr = process.communicate(input)
|
|
|
|
except:
|
|
|
|
process.kill()
|
|
|
|
process.wait()
|
|
|
|
raise
|
|
|
|
returncode = process.poll()
|
|
|
|
if check and returncode:
|
|
|
|
raise subprocess.CalledProcessError(returncode, popenargs)
|
|
|
|
return _CompletedProcess(popenargs, returncode, stdout, stderr)
|
|
|
|
|
|
|
|
subprocess.run = _run
|
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
2016-11-14 23:48:50 +00:00
|
|
|
class Context(object):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""The global state associated with builds in a given directory."""
|
|
|
|
|
2016-12-07 21:29:24 +00:00
|
|
|
def __init__(self, topdir, parallelism, keep, replace_sources, strip,
|
2020-02-28 11:32:28 +00:00
|
|
|
full_gcc, action, shallow=False):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""Initialize the context."""
|
|
|
|
self.topdir = topdir
|
|
|
|
self.parallelism = parallelism
|
|
|
|
self.keep = keep
|
2016-11-24 22:25:58 +00:00
|
|
|
self.replace_sources = replace_sources
|
2016-12-07 21:29:24 +00:00
|
|
|
self.strip = strip
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
self.full_gcc = full_gcc
|
2020-02-28 11:32:28 +00:00
|
|
|
self.shallow = shallow
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.srcdir = os.path.join(topdir, 'src')
|
2016-11-24 22:25:58 +00:00
|
|
|
self.versions_json = os.path.join(self.srcdir, 'versions.json')
|
2016-11-26 00:10:24 +00:00
|
|
|
self.build_state_json = os.path.join(topdir, 'build-state.json')
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
self.bot_config_json = os.path.join(topdir, 'bot-config.json')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.installdir = os.path.join(topdir, 'install')
|
|
|
|
self.host_libraries_installdir = os.path.join(self.installdir,
|
|
|
|
'host-libraries')
|
|
|
|
self.builddir = os.path.join(topdir, 'build')
|
|
|
|
self.logsdir = os.path.join(topdir, 'logs')
|
2016-12-01 00:09:25 +00:00
|
|
|
self.logsdir_old = os.path.join(topdir, 'logs-old')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.makefile = os.path.join(self.builddir, 'Makefile')
|
|
|
|
self.wrapper = os.path.join(self.builddir, 'wrapper')
|
|
|
|
self.save_logs = os.path.join(self.builddir, 'save-logs')
|
2016-11-25 00:58:22 +00:00
|
|
|
self.script_text = self.get_script_text()
|
2020-02-29 11:44:31 +00:00
|
|
|
if action not in ('checkout', 'list-compilers', 'list-glibcs'):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.build_triplet = self.get_build_triplet()
|
|
|
|
self.glibc_version = self.get_glibc_version()
|
|
|
|
self.configs = {}
|
|
|
|
self.glibc_configs = {}
|
|
|
|
self.makefile_pieces = ['.PHONY: all\n']
|
|
|
|
self.add_all_configs()
|
2016-11-24 22:25:58 +00:00
|
|
|
self.load_versions_json()
|
2016-11-26 00:10:24 +00:00
|
|
|
self.load_build_state_json()
|
|
|
|
self.status_log_list = []
|
2017-02-16 21:57:35 +00:00
|
|
|
self.email_warning = False
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
2016-11-25 00:58:22 +00:00
|
|
|
def get_script_text(self):
|
|
|
|
"""Return the text of this script."""
|
|
|
|
with open(sys.argv[0], 'r') as f:
|
|
|
|
return f.read()
|
|
|
|
|
|
|
|
def exec_self(self):
|
|
|
|
"""Re-execute this script with the same arguments."""
|
2016-12-16 16:17:13 +00:00
|
|
|
sys.stdout.flush()
|
2016-11-25 00:58:22 +00:00
|
|
|
os.execv(sys.executable, [sys.executable] + sys.argv)
|
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
def get_build_triplet(self):
|
|
|
|
"""Determine the build triplet with config.guess."""
|
|
|
|
config_guess = os.path.join(self.component_srcdir('gcc'),
|
|
|
|
'config.guess')
|
|
|
|
cg_out = subprocess.run([config_guess], stdout=subprocess.PIPE,
|
|
|
|
check=True, universal_newlines=True).stdout
|
|
|
|
return cg_out.rstrip()
|
|
|
|
|
|
|
|
def get_glibc_version(self):
|
|
|
|
"""Determine the glibc version number (major.minor)."""
|
|
|
|
version_h = os.path.join(self.component_srcdir('glibc'), 'version.h')
|
|
|
|
with open(version_h, 'r') as f:
|
|
|
|
lines = f.readlines()
|
|
|
|
starttext = '#define VERSION "'
|
|
|
|
for l in lines:
|
|
|
|
if l.startswith(starttext):
|
|
|
|
l = l[len(starttext):]
|
|
|
|
l = l.rstrip('"\n')
|
2024-01-10 13:01:39 +00:00
|
|
|
m = re.fullmatch(r'([0-9]+)\.([0-9]+)[.0-9]*', l)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
return '%s.%s' % m.group(1, 2)
|
|
|
|
print('error: could not determine glibc version')
|
|
|
|
exit(1)
|
|
|
|
|
|
|
|
def add_all_configs(self):
|
|
|
|
"""Add all known glibc build configurations."""
|
|
|
|
self.add_config(arch='aarch64',
|
2017-12-20 11:00:29 +00:00
|
|
|
os_name='linux-gnu',
|
|
|
|
extra_glibcs=[{'variant': 'disable-multi-arch',
|
|
|
|
'cfg': ['--disable-multi-arch']}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='aarch64_be',
|
|
|
|
os_name='linux-gnu')
|
2020-03-13 01:29:59 +00:00
|
|
|
self.add_config(arch='arc',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--disable-multilib', '--with-cpu=hs38'])
|
|
|
|
self.add_config(arch='arc',
|
|
|
|
os_name='linux-gnuhf',
|
|
|
|
gcc_cfg=['--disable-multilib', '--with-cpu=hs38_linux'])
|
|
|
|
self.add_config(arch='arceb',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--disable-multilib', '--with-cpu=hs38'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='alpha',
|
|
|
|
os_name='linux-gnu')
|
|
|
|
self.add_config(arch='arm',
|
2019-07-02 11:14:58 +00:00
|
|
|
os_name='linux-gnueabi',
|
|
|
|
extra_glibcs=[{'variant': 'v4t',
|
|
|
|
'ccopts': '-march=armv4t'}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='armeb',
|
|
|
|
os_name='linux-gnueabi')
|
|
|
|
self.add_config(arch='armeb',
|
|
|
|
os_name='linux-gnueabi',
|
|
|
|
variant='be8',
|
|
|
|
gcc_cfg=['--with-arch=armv7-a'])
|
|
|
|
self.add_config(arch='arm',
|
2017-10-09 18:53:33 +00:00
|
|
|
os_name='linux-gnueabihf',
|
2017-12-19 00:08:49 +00:00
|
|
|
gcc_cfg=['--with-float=hard', '--with-cpu=arm926ej-s'],
|
2017-10-09 18:53:33 +00:00
|
|
|
extra_glibcs=[{'variant': 'v7a',
|
2017-12-19 00:08:49 +00:00
|
|
|
'ccopts': '-march=armv7-a -mfpu=vfpv3'},
|
2021-07-09 08:59:22 +00:00
|
|
|
{'variant': 'thumb',
|
|
|
|
'ccopts':
|
|
|
|
'-mthumb -march=armv7-a -mfpu=vfpv3'},
|
2017-10-09 18:53:33 +00:00
|
|
|
{'variant': 'v7a-disable-multi-arch',
|
2017-12-19 00:08:49 +00:00
|
|
|
'ccopts': '-march=armv7-a -mfpu=vfpv3',
|
2017-10-09 18:53:33 +00:00
|
|
|
'cfg': ['--disable-multi-arch']}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='armeb',
|
2017-12-15 16:57:29 +00:00
|
|
|
os_name='linux-gnueabihf',
|
2017-12-19 00:08:49 +00:00
|
|
|
gcc_cfg=['--with-float=hard', '--with-cpu=arm926ej-s'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='armeb',
|
|
|
|
os_name='linux-gnueabihf',
|
|
|
|
variant='be8',
|
2017-12-19 00:08:49 +00:00
|
|
|
gcc_cfg=['--with-float=hard', '--with-arch=armv7-a',
|
|
|
|
'--with-fpu=vfpv3'])
|
2018-12-21 01:48:04 +00:00
|
|
|
self.add_config(arch='csky',
|
|
|
|
os_name='linux-gnuabiv2',
|
|
|
|
variant='soft',
|
|
|
|
gcc_cfg=['--disable-multilib'])
|
|
|
|
self.add_config(arch='csky',
|
|
|
|
os_name='linux-gnuabiv2',
|
|
|
|
gcc_cfg=['--with-float=hard', '--disable-multilib'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='hppa',
|
|
|
|
os_name='linux-gnu')
|
2018-01-24 01:18:54 +00:00
|
|
|
self.add_config(arch='i686',
|
|
|
|
os_name='gnu')
|
2022-07-19 01:22:09 +00:00
|
|
|
self.add_config(arch='loongarch64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='lp64d',
|
|
|
|
gcc_cfg=['--with-abi=lp64d','--disable-multilib'])
|
2022-08-22 08:00:51 +00:00
|
|
|
self.add_config(arch='loongarch64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='lp64s',
|
|
|
|
gcc_cfg=['--with-abi=lp64s','--disable-multilib'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='m68k',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--disable-multilib'])
|
|
|
|
self.add_config(arch='m68k',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='coldfire',
|
|
|
|
gcc_cfg=['--with-arch=cf', '--disable-multilib'])
|
2018-01-24 23:48:52 +00:00
|
|
|
self.add_config(arch='m68k',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='coldfire-soft',
|
|
|
|
gcc_cfg=['--with-arch=cf', '--with-cpu=54455',
|
|
|
|
'--disable-multilib'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='microblaze',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--disable-multilib'])
|
|
|
|
self.add_config(arch='microblazeel',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--disable-multilib'])
|
|
|
|
self.add_config(arch='mips64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--with-mips-plt'],
|
|
|
|
glibcs=[{'variant': 'n32'},
|
|
|
|
{'arch': 'mips',
|
|
|
|
'ccopts': '-mabi=32'},
|
|
|
|
{'variant': 'n64',
|
|
|
|
'ccopts': '-mabi=64'}])
|
|
|
|
self.add_config(arch='mips64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='soft',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-float=soft'],
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
glibcs=[{'variant': 'n32-soft'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'soft',
|
|
|
|
'arch': 'mips',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=32'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'n64-soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=64'}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='mips64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='nan2008',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-nan=2008',
|
|
|
|
'--with-arch-64=mips64r2',
|
|
|
|
'--with-arch-32=mips32r2'],
|
|
|
|
glibcs=[{'variant': 'n32-nan2008'},
|
|
|
|
{'variant': 'nan2008',
|
|
|
|
'arch': 'mips',
|
|
|
|
'ccopts': '-mabi=32'},
|
|
|
|
{'variant': 'n64-nan2008',
|
|
|
|
'ccopts': '-mabi=64'}])
|
|
|
|
self.add_config(arch='mips64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='nan2008-soft',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-nan=2008',
|
|
|
|
'--with-arch-64=mips64r2',
|
|
|
|
'--with-arch-32=mips32r2',
|
|
|
|
'--with-float=soft'],
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
glibcs=[{'variant': 'n32-nan2008-soft'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'nan2008-soft',
|
|
|
|
'arch': 'mips',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=32'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'n64-nan2008-soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=64'}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='mips64el',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--with-mips-plt'],
|
|
|
|
glibcs=[{'variant': 'n32'},
|
|
|
|
{'arch': 'mipsel',
|
|
|
|
'ccopts': '-mabi=32'},
|
|
|
|
{'variant': 'n64',
|
|
|
|
'ccopts': '-mabi=64'}])
|
|
|
|
self.add_config(arch='mips64el',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='soft',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-float=soft'],
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
glibcs=[{'variant': 'n32-soft'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'soft',
|
|
|
|
'arch': 'mipsel',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=32'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'n64-soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=64'}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='mips64el',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='nan2008',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-nan=2008',
|
|
|
|
'--with-arch-64=mips64r2',
|
|
|
|
'--with-arch-32=mips32r2'],
|
|
|
|
glibcs=[{'variant': 'n32-nan2008'},
|
|
|
|
{'variant': 'nan2008',
|
|
|
|
'arch': 'mipsel',
|
|
|
|
'ccopts': '-mabi=32'},
|
|
|
|
{'variant': 'n64-nan2008',
|
|
|
|
'ccopts': '-mabi=64'}])
|
|
|
|
self.add_config(arch='mips64el',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='nan2008-soft',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-nan=2008',
|
|
|
|
'--with-arch-64=mips64r2',
|
|
|
|
'--with-arch-32=mips32r2',
|
|
|
|
'--with-float=soft'],
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
glibcs=[{'variant': 'n32-nan2008-soft'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'nan2008-soft',
|
|
|
|
'arch': 'mipsel',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=32'},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'n64-nan2008-soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'ccopts': '-mabi=64'}])
|
2019-12-11 10:23:04 +00:00
|
|
|
self.add_config(arch='mipsisa64r6el',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--with-mips-plt', '--with-nan=2008',
|
|
|
|
'--with-arch-64=mips64r6',
|
|
|
|
'--with-arch-32=mips32r6',
|
|
|
|
'--with-float=hard'],
|
|
|
|
glibcs=[{'variant': 'n32'},
|
|
|
|
{'arch': 'mipsisa32r6el',
|
|
|
|
'ccopts': '-mabi=32'},
|
|
|
|
{'variant': 'n64',
|
|
|
|
'ccopts': '-mabi=64'}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='nios2',
|
|
|
|
os_name='linux-gnu')
|
2021-10-19 21:54:48 +00:00
|
|
|
self.add_config(arch='or1k',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='soft',
|
|
|
|
gcc_cfg=['--with-multilib-list=mcmov'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='powerpc',
|
|
|
|
os_name='linux-gnu',
|
2017-01-02 22:13:42 +00:00
|
|
|
gcc_cfg=['--disable-multilib', '--enable-secureplt'],
|
|
|
|
extra_glibcs=[{'variant': 'power4',
|
|
|
|
'ccopts': '-mcpu=power4',
|
|
|
|
'cfg': ['--with-cpu=power4']}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='powerpc',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='soft',
|
|
|
|
gcc_cfg=['--disable-multilib', '--with-float=soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
'--enable-secureplt'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='powerpc64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--disable-multilib', '--enable-secureplt'])
|
|
|
|
self.add_config(arch='powerpc64le',
|
|
|
|
os_name='linux-gnu',
|
2021-09-23 20:25:00 +00:00
|
|
|
gcc_cfg=['--disable-multilib', '--enable-secureplt'],
|
|
|
|
extra_glibcs=[{'variant': 'disable-multi-arch',
|
|
|
|
'cfg': ['--disable-multi-arch']}])
|
2018-11-30 09:18:40 +00:00
|
|
|
self.add_config(arch='riscv32',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='rv32imac-ilp32',
|
|
|
|
gcc_cfg=['--with-arch=rv32imac', '--with-abi=ilp32',
|
|
|
|
'--disable-multilib'])
|
|
|
|
self.add_config(arch='riscv32',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='rv32imafdc-ilp32',
|
|
|
|
gcc_cfg=['--with-arch=rv32imafdc', '--with-abi=ilp32',
|
|
|
|
'--disable-multilib'])
|
|
|
|
self.add_config(arch='riscv32',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='rv32imafdc-ilp32d',
|
|
|
|
gcc_cfg=['--with-arch=rv32imafdc', '--with-abi=ilp32d',
|
|
|
|
'--disable-multilib'])
|
Add RISC-V to build-many-glibcs.py
For full disclosure, I've only run build-many-glibcs.py with the
additional diff below.
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index 1c7b85050b57..22cc7b427041 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -706,7 +706,7 @@ class Context(object):
'gcc': 'vcs-7',
'glibc': 'vcs-mainline',
'gmp': '6.1.2',
- 'linux': '4.14',
+ 'linux': '4.15-rc8',
'mpc': '1.0.3',
'mpfr': '3.1.6'}
use_versions = {}
@@ -841,7 +841,7 @@ class Context(object):
url_map = {'binutils':
'https://ftp.gnu.org/gnu/binutils/binutils-%(version)s.tar.bz2',
'gcc':
'https://ftp.gnu.org/gnu/gcc/gcc-%(version)s/gcc-%(version)s.tar.bz2',
'gmp':
'https://ftp.gnu.org/gnu/gmp/gmp-%(version)s.tar.xz',
- 'linux':
'https://www.kernel.org/pub/linux/kernel/v4.x/linux-%(version)s.tar.xz',
+ 'linux':
'https://git.kernel.org/torvalds/t/linux-%(version)s.tar.gz',
'mpc':
'https://ftp.gnu.org/gnu/mpc/mpc-%(version)s.tar.gz',
'mpfr':
'https://ftp.gnu.org/gnu/mpfr/mpfr-%(version)s.tar.xz'}
if component not in url_map:
2018-01-29 Palmer Dabbelt <palmer@sifive.com>
* scripts/build-many-glibcs.py (Context): Add RISC-V targets.
(Config): Likewise.
2018-01-29 18:30:51 +00:00
|
|
|
self.add_config(arch='riscv64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='rv64imac-lp64',
|
|
|
|
gcc_cfg=['--with-arch=rv64imac', '--with-abi=lp64',
|
|
|
|
'--disable-multilib'])
|
|
|
|
self.add_config(arch='riscv64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='rv64imafdc-lp64',
|
|
|
|
gcc_cfg=['--with-arch=rv64imafdc', '--with-abi=lp64',
|
|
|
|
'--disable-multilib'])
|
|
|
|
self.add_config(arch='riscv64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='rv64imafdc-lp64d',
|
|
|
|
gcc_cfg=['--with-arch=rv64imafdc', '--with-abi=lp64d',
|
|
|
|
'--disable-multilib'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='s390x',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
glibcs=[{},
|
2020-08-20 08:51:42 +00:00
|
|
|
{'arch': 's390', 'ccopts': '-m31'}],
|
|
|
|
extra_glibcs=[{'variant': 'O3',
|
2024-01-31 12:02:57 +00:00
|
|
|
'cflags': '-O3'},
|
|
|
|
{'variant': 'zEC12',
|
|
|
|
'ccopts': '-march=zEC12'},
|
|
|
|
{'variant': 'z13',
|
|
|
|
'ccopts': '-march=z13'},
|
|
|
|
{'variant': 'z15',
|
|
|
|
'ccopts': '-march=z15'},
|
|
|
|
{'variant': 'zEC12-disable-multi-arch',
|
|
|
|
'ccopts': '-march=zEC12',
|
|
|
|
'cfg': ['--disable-multi-arch']},
|
|
|
|
{'variant': 'z13-disable-multi-arch',
|
|
|
|
'ccopts': '-march=z13',
|
|
|
|
'cfg': ['--disable-multi-arch']},
|
|
|
|
{'variant': 'z15-disable-multi-arch',
|
|
|
|
'ccopts': '-march=z15',
|
|
|
|
'cfg': ['--disable-multi-arch']}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sh3',
|
2017-03-13 11:04:22 +00:00
|
|
|
os_name='linux-gnu')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sh3eb',
|
2017-03-13 11:04:22 +00:00
|
|
|
os_name='linux-gnu')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sh4',
|
2017-03-13 11:04:22 +00:00
|
|
|
os_name='linux-gnu')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sh4eb',
|
2017-03-13 11:04:22 +00:00
|
|
|
os_name='linux-gnu')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sh4',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
gcc_cfg=['--without-fp'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sh4eb',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
variant='soft',
|
Remove --with-fp / --without-fp.
There is a configure option --without-fp that specifies that nofpu
sysdeps directories should be used instead of fpu directories.
For most glibc configurations, this option is of no use: either there
is no valid nofpu variant of that configuration, or there are no fpu
or nofpu sysdeps directories for that processor and so the option does
nothing. For a few configurations, if you are using a soft-float
compiler this option is required, and failing to use it generally
results in compilation errors from inline asm using unavailable
floating-point instructions.
We're moving away from --with-cpu to configuring glibc based on how
the compiler generates code, and it is natural to do so for
--without-fp as well; in most cases the soft-float and hard-float ABIs
are incompatible so you have no hope of building a working glibc with
an inappropriately configured compiler or libgcc.
This patch eliminates --without-fp, replacing it entirely by automatic
configuration based on the compiler. Configurations for which this is
relevant (coldfire / mips / powerpc32 / sh) define a variable
with_fp_cond in their preconfigure fragments (under the same
conditions under which those fragments do anything); this is a
preprocessor conditional which the toplevel configure script then uses
in a test to determine which sysdeps directories to use.
The config.make with-fp variable remains. It's used only by powerpc
(sysdeps/powerpc/powerpc32/Makefile) to add -mhard-float to various
flags variables. For powerpc, -mcpu= options can imply use of
soft-float. That could be an issue if you want to build for
e.g. 476fp, but are using --with-cpu=476 because there isn't a 476fp
sysdeps directory. If in future we eliminate --with-cpu and replace
it entirely by testing the compiler, it would be natural at that point
to eliminate that code as well (as the user should then just use a
compiler defaulting to 476fp and the 476 sysdeps directory would be
used automatically).
Tested for x86_64, and tested with build-many-glibcs.py that installed
shared libraries are unchanged by this patch.
* configure.ac (--with-fp): Remove configure option.
(with_fp_cond): New variable.
(libc_cv_with_fp): New configure test. Use this variable instead
of with_fp.
* configure: Regenerated.
* config.make.in (with-fp): Use @libc_cv_with_fp@.
* manual/install.texi (Configuring and compiling): Remove
--without-fp.
* INSTALL: Regenerated.
* sysdeps/m68k/preconfigure (with_fp_cond): Define for ColdFire.
* sysdeps/mips/preconfigure (with_fp_cond): Define.
* sysdeps/powerpc/preconfigure (with_fp_cond): Define for 32-bit.
* sysdeps/sh/preconfigure (with_fp_cond): Define.
* scripts/build-many-glibcs.py (Context.add_all_configs): Do not
use --without-fp to configure glibc.
2017-12-12 13:56:47 +00:00
|
|
|
gcc_cfg=['--without-fp'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='sparc64',
|
|
|
|
os_name='linux-gnu',
|
2024-01-17 12:24:55 +00:00
|
|
|
glibcs=[{'cfg' : ['--disable-default-pie']},
|
|
|
|
{'cfg' : ['--disable-default-pie'],
|
|
|
|
'arch': 'sparcv9',
|
2019-11-13 12:32:17 +00:00
|
|
|
'ccopts': '-m32 -mlong-double-128 -mcpu=v9'}],
|
2019-12-03 12:18:49 +00:00
|
|
|
extra_glibcs=[{'variant': 'leon3',
|
2024-01-17 12:24:55 +00:00
|
|
|
'cfg' : ['--disable-default-pie'],
|
2019-12-03 12:18:49 +00:00
|
|
|
'arch' : 'sparcv8',
|
|
|
|
'ccopts' : '-m32 -mlong-double-128 -mcpu=leon3'},
|
|
|
|
{'variant': 'disable-multi-arch',
|
2024-01-17 12:24:55 +00:00
|
|
|
'cfg': ['--disable-multi-arch', '--disable-default-pie']},
|
2017-11-29 22:51:46 +00:00
|
|
|
{'variant': 'disable-multi-arch',
|
|
|
|
'arch': 'sparcv9',
|
2019-12-03 12:18:49 +00:00
|
|
|
'ccopts': '-m32 -mlong-double-128 -mcpu=v9',
|
2024-01-17 12:24:55 +00:00
|
|
|
'cfg': ['--disable-multi-arch', '--disable-default-pie']}])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.add_config(arch='x86_64',
|
|
|
|
os_name='linux-gnu',
|
|
|
|
gcc_cfg=['--with-multilib-list=m64,m32,mx32'],
|
|
|
|
glibcs=[{},
|
|
|
|
{'variant': 'x32', 'ccopts': '-mx32'},
|
|
|
|
{'arch': 'i686', 'ccopts': '-m32 -march=i686'}],
|
|
|
|
extra_glibcs=[{'variant': 'disable-multi-arch',
|
|
|
|
'cfg': ['--disable-multi-arch']},
|
2021-07-28 12:47:33 +00:00
|
|
|
{'variant': 'minimal',
|
|
|
|
'cfg': ['--disable-multi-arch',
|
|
|
|
'--disable-profile',
|
|
|
|
'--disable-timezone-tools',
|
|
|
|
'--disable-mathvec',
|
|
|
|
'--disable-build-nscd',
|
|
|
|
'--disable-nscd']},
|
2021-12-08 05:51:26 +00:00
|
|
|
{'variant': 'no-pie',
|
|
|
|
'cfg': ['--disable-default-pie']},
|
|
|
|
{'variant': 'x32-no-pie',
|
2017-12-19 02:11:17 +00:00
|
|
|
'ccopts': '-mx32',
|
2021-12-08 05:51:26 +00:00
|
|
|
'cfg': ['--disable-default-pie']},
|
|
|
|
{'variant': 'no-pie',
|
2017-12-19 02:11:17 +00:00
|
|
|
'arch': 'i686',
|
|
|
|
'ccopts': '-m32 -march=i686',
|
2021-12-08 05:51:26 +00:00
|
|
|
'cfg': ['--disable-default-pie']},
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
{'variant': 'disable-multi-arch',
|
|
|
|
'arch': 'i686',
|
|
|
|
'ccopts': '-m32 -march=i686',
|
|
|
|
'cfg': ['--disable-multi-arch']},
|
|
|
|
{'arch': 'i486',
|
|
|
|
'ccopts': '-m32 -march=i486'},
|
|
|
|
{'arch': 'i586',
|
2023-03-17 09:14:50 +00:00
|
|
|
'ccopts': '-m32 -march=i586'},
|
|
|
|
{'variant': 'enable-fortify-source',
|
2023-10-02 12:11:49 +00:00
|
|
|
'cfg': ['--enable-fortify-source']}])
|
2023-05-02 19:40:31 +00:00
|
|
|
self.add_config(arch='x86_64',
|
|
|
|
os_name='gnu',
|
|
|
|
gcc_cfg=['--disable-multilib'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def add_config(self, **args):
|
|
|
|
"""Add an individual build configuration."""
|
|
|
|
cfg = Config(self, **args)
|
|
|
|
if cfg.name in self.configs:
|
|
|
|
print('error: duplicate config %s' % cfg.name)
|
|
|
|
exit(1)
|
|
|
|
self.configs[cfg.name] = cfg
|
|
|
|
for c in cfg.all_glibcs:
|
|
|
|
if c.name in self.glibc_configs:
|
|
|
|
print('error: duplicate glibc config %s' % c.name)
|
|
|
|
exit(1)
|
|
|
|
self.glibc_configs[c.name] = c
|
|
|
|
|
|
|
|
def component_srcdir(self, component):
|
|
|
|
"""Return the source directory for a given component, e.g. gcc."""
|
|
|
|
return os.path.join(self.srcdir, component)
|
|
|
|
|
|
|
|
def component_builddir(self, action, config, component, subconfig=None):
|
|
|
|
"""Return the directory to use for a build."""
|
|
|
|
if config is None:
|
|
|
|
# Host libraries.
|
|
|
|
assert subconfig is None
|
|
|
|
return os.path.join(self.builddir, action, component)
|
|
|
|
if subconfig is None:
|
|
|
|
return os.path.join(self.builddir, action, config, component)
|
|
|
|
else:
|
|
|
|
# glibc build as part of compiler build.
|
|
|
|
return os.path.join(self.builddir, action, config, component,
|
|
|
|
subconfig)
|
|
|
|
|
|
|
|
def compiler_installdir(self, config):
|
|
|
|
"""Return the directory in which to install a compiler."""
|
|
|
|
return os.path.join(self.installdir, 'compilers', config)
|
|
|
|
|
|
|
|
def compiler_bindir(self, config):
|
|
|
|
"""Return the directory in which to find compiler binaries."""
|
|
|
|
return os.path.join(self.compiler_installdir(config), 'bin')
|
|
|
|
|
|
|
|
def compiler_sysroot(self, config):
|
|
|
|
"""Return the sysroot directory for a compiler."""
|
|
|
|
return os.path.join(self.compiler_installdir(config), 'sysroot')
|
|
|
|
|
|
|
|
def glibc_installdir(self, config):
|
|
|
|
"""Return the directory in which to install glibc."""
|
|
|
|
return os.path.join(self.installdir, 'glibcs', config)
|
|
|
|
|
|
|
|
def run_builds(self, action, configs):
|
|
|
|
"""Run the requested builds."""
|
|
|
|
if action == 'checkout':
|
|
|
|
self.checkout(configs)
|
|
|
|
return
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
if action == 'bot-cycle':
|
|
|
|
if configs:
|
|
|
|
print('error: configurations specified for bot-cycle')
|
|
|
|
exit(1)
|
|
|
|
self.bot_cycle()
|
|
|
|
return
|
2016-12-01 00:09:25 +00:00
|
|
|
if action == 'bot':
|
|
|
|
if configs:
|
|
|
|
print('error: configurations specified for bot')
|
|
|
|
exit(1)
|
|
|
|
self.bot()
|
|
|
|
return
|
2020-02-29 11:44:31 +00:00
|
|
|
if action in ('host-libraries', 'list-compilers',
|
|
|
|
'list-glibcs') and configs:
|
|
|
|
print('error: configurations specified for ' + action)
|
2016-11-26 00:10:24 +00:00
|
|
|
exit(1)
|
2020-02-29 11:44:31 +00:00
|
|
|
if action == 'list-compilers':
|
|
|
|
for name in sorted(self.configs.keys()):
|
|
|
|
print(name)
|
|
|
|
return
|
|
|
|
if action == 'list-glibcs':
|
|
|
|
for config in sorted(self.glibc_configs.values(),
|
|
|
|
key=lambda c: c.name):
|
|
|
|
print(config.name, config.compiler.name)
|
|
|
|
return
|
2016-11-26 00:10:24 +00:00
|
|
|
self.clear_last_build_state(action)
|
2024-01-10 13:02:16 +00:00
|
|
|
build_time = datetime.datetime.now(datetime.timezone.utc)
|
2016-11-26 00:10:24 +00:00
|
|
|
if action == 'host-libraries':
|
|
|
|
build_components = ('gmp', 'mpfr', 'mpc')
|
|
|
|
old_components = ()
|
|
|
|
old_versions = {}
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.build_host_libraries()
|
|
|
|
elif action == 'compilers':
|
2018-01-24 01:18:54 +00:00
|
|
|
build_components = ('binutils', 'gcc', 'glibc', 'linux', 'mig',
|
|
|
|
'gnumach', 'hurd')
|
2016-11-26 00:10:24 +00:00
|
|
|
old_components = ('gmp', 'mpfr', 'mpc')
|
|
|
|
old_versions = self.build_state['host-libraries']['build-versions']
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.build_compilers(configs)
|
|
|
|
else:
|
2016-11-26 00:10:24 +00:00
|
|
|
build_components = ('glibc',)
|
2018-01-24 01:18:54 +00:00
|
|
|
old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux',
|
|
|
|
'mig', 'gnumach', 'hurd')
|
2016-11-26 00:10:24 +00:00
|
|
|
old_versions = self.build_state['compilers']['build-versions']
|
2020-01-02 09:18:34 +00:00
|
|
|
if action == 'update-syscalls':
|
|
|
|
self.update_syscalls(configs)
|
|
|
|
else:
|
|
|
|
self.build_glibcs(configs)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.write_files()
|
|
|
|
self.do_build()
|
2016-11-26 00:10:24 +00:00
|
|
|
if configs:
|
|
|
|
# Partial build, do not update stored state.
|
|
|
|
return
|
|
|
|
build_versions = {}
|
|
|
|
for k in build_components:
|
|
|
|
if k in self.versions:
|
|
|
|
build_versions[k] = {'version': self.versions[k]['version'],
|
|
|
|
'revision': self.versions[k]['revision']}
|
|
|
|
for k in old_components:
|
|
|
|
if k in old_versions:
|
|
|
|
build_versions[k] = {'version': old_versions[k]['version'],
|
|
|
|
'revision': old_versions[k]['revision']}
|
|
|
|
self.update_build_state(action, build_time, build_versions)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def remove_dirs(*args):
|
|
|
|
"""Remove directories and their contents if they exist."""
|
|
|
|
for dir in args:
|
|
|
|
shutil.rmtree(dir, ignore_errors=True)
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def remove_recreate_dirs(*args):
|
|
|
|
"""Remove directories if they exist, and create them as empty."""
|
|
|
|
Context.remove_dirs(*args)
|
|
|
|
for dir in args:
|
|
|
|
os.makedirs(dir, exist_ok=True)
|
|
|
|
|
|
|
|
def add_makefile_cmdlist(self, target, cmdlist, logsdir):
|
|
|
|
"""Add makefile text for a list of commands."""
|
|
|
|
commands = cmdlist.makefile_commands(self.wrapper, logsdir)
|
|
|
|
self.makefile_pieces.append('all: %s\n.PHONY: %s\n%s:\n%s\n' %
|
|
|
|
(target, target, target, commands))
|
2016-11-26 00:10:24 +00:00
|
|
|
self.status_log_list.extend(cmdlist.status_logs(logsdir))
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def write_files(self):
|
|
|
|
"""Write out the Makefile and wrapper script."""
|
|
|
|
mftext = ''.join(self.makefile_pieces)
|
|
|
|
with open(self.makefile, 'w') as f:
|
|
|
|
f.write(mftext)
|
|
|
|
wrapper_text = (
|
|
|
|
'#!/bin/sh\n'
|
|
|
|
'prev_base=$1\n'
|
|
|
|
'this_base=$2\n'
|
|
|
|
'desc=$3\n'
|
|
|
|
'dir=$4\n'
|
|
|
|
'path=$5\n'
|
|
|
|
'shift 5\n'
|
|
|
|
'prev_status=$prev_base-status.txt\n'
|
|
|
|
'this_status=$this_base-status.txt\n'
|
|
|
|
'this_log=$this_base-log.txt\n'
|
|
|
|
'date > "$this_log"\n'
|
|
|
|
'echo >> "$this_log"\n'
|
|
|
|
'echo "Description: $desc" >> "$this_log"\n'
|
2016-11-18 18:22:09 +00:00
|
|
|
'printf "%s" "Command:" >> "$this_log"\n'
|
|
|
|
'for word in "$@"; do\n'
|
|
|
|
' if expr "$word" : "[]+,./0-9@A-Z_a-z-]\\\\{1,\\\\}\\$" > /dev/null; then\n'
|
|
|
|
' printf " %s" "$word"\n'
|
|
|
|
' else\n'
|
|
|
|
' printf " \'"\n'
|
|
|
|
' printf "%s" "$word" | sed -e "s/\'/\'\\\\\\\\\'\'/"\n'
|
|
|
|
' printf "\'"\n'
|
|
|
|
' fi\n'
|
|
|
|
'done >> "$this_log"\n'
|
|
|
|
'echo >> "$this_log"\n'
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'echo "Directory: $dir" >> "$this_log"\n'
|
|
|
|
'echo "Path addition: $path" >> "$this_log"\n'
|
|
|
|
'echo >> "$this_log"\n'
|
|
|
|
'record_status ()\n'
|
|
|
|
'{\n'
|
|
|
|
' echo >> "$this_log"\n'
|
|
|
|
' echo "$1: $desc" > "$this_status"\n'
|
|
|
|
' echo "$1: $desc" >> "$this_log"\n'
|
|
|
|
' echo >> "$this_log"\n'
|
|
|
|
' date >> "$this_log"\n'
|
|
|
|
' echo "$1: $desc"\n'
|
|
|
|
' exit 0\n'
|
|
|
|
'}\n'
|
|
|
|
'check_error ()\n'
|
|
|
|
'{\n'
|
|
|
|
' if [ "$1" != "0" ]; then\n'
|
|
|
|
' record_status FAIL\n'
|
|
|
|
' fi\n'
|
|
|
|
'}\n'
|
|
|
|
'if [ "$prev_base" ] && ! grep -q "^PASS" "$prev_status"; then\n'
|
|
|
|
' record_status UNRESOLVED\n'
|
|
|
|
'fi\n'
|
|
|
|
'if [ "$dir" ]; then\n'
|
|
|
|
' cd "$dir"\n'
|
|
|
|
' check_error "$?"\n'
|
|
|
|
'fi\n'
|
|
|
|
'if [ "$path" ]; then\n'
|
|
|
|
' PATH=$path:$PATH\n'
|
|
|
|
'fi\n'
|
|
|
|
'"$@" < /dev/null >> "$this_log" 2>&1\n'
|
|
|
|
'check_error "$?"\n'
|
|
|
|
'record_status PASS\n')
|
|
|
|
with open(self.wrapper, 'w') as f:
|
|
|
|
f.write(wrapper_text)
|
2016-11-14 23:48:50 +00:00
|
|
|
# Mode 0o755.
|
|
|
|
mode_exec = (stat.S_IRWXU|stat.S_IRGRP|stat.S_IXGRP|
|
|
|
|
stat.S_IROTH|stat.S_IXOTH)
|
|
|
|
os.chmod(self.wrapper, mode_exec)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
save_logs_text = (
|
|
|
|
'#!/bin/sh\n'
|
|
|
|
'if ! [ -f tests.sum ]; then\n'
|
|
|
|
' echo "No test summary available."\n'
|
|
|
|
' exit 0\n'
|
|
|
|
'fi\n'
|
|
|
|
'save_file ()\n'
|
|
|
|
'{\n'
|
|
|
|
' echo "Contents of $1:"\n'
|
|
|
|
' echo\n'
|
|
|
|
' cat "$1"\n'
|
|
|
|
' echo\n'
|
|
|
|
' echo "End of contents of $1."\n'
|
|
|
|
' echo\n'
|
|
|
|
'}\n'
|
|
|
|
'save_file tests.sum\n'
|
|
|
|
'non_pass_tests=$(grep -v "^PASS: " tests.sum | sed -e "s/^PASS: //")\n'
|
|
|
|
'for t in $non_pass_tests; do\n'
|
|
|
|
' if [ -f "$t.out" ]; then\n'
|
|
|
|
' save_file "$t.out"\n'
|
|
|
|
' fi\n'
|
|
|
|
'done\n')
|
|
|
|
with open(self.save_logs, 'w') as f:
|
|
|
|
f.write(save_logs_text)
|
2016-11-14 23:48:50 +00:00
|
|
|
os.chmod(self.save_logs, mode_exec)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def do_build(self):
|
|
|
|
"""Do the actual build."""
|
2021-02-22 08:39:14 +00:00
|
|
|
cmd = ['make', '-O', '-j%d' % self.parallelism]
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
subprocess.run(cmd, cwd=self.builddir, check=True)
|
|
|
|
|
|
|
|
def build_host_libraries(self):
|
|
|
|
"""Build the host libraries."""
|
|
|
|
installdir = self.host_libraries_installdir
|
|
|
|
builddir = os.path.join(self.builddir, 'host-libraries')
|
|
|
|
logsdir = os.path.join(self.logsdir, 'host-libraries')
|
|
|
|
self.remove_recreate_dirs(installdir, builddir, logsdir)
|
|
|
|
cmdlist = CommandList('host-libraries', self.keep)
|
|
|
|
self.build_host_library(cmdlist, 'gmp')
|
|
|
|
self.build_host_library(cmdlist, 'mpfr',
|
|
|
|
['--with-gmp=%s' % installdir])
|
|
|
|
self.build_host_library(cmdlist, 'mpc',
|
|
|
|
['--with-gmp=%s' % installdir,
|
|
|
|
'--with-mpfr=%s' % installdir])
|
|
|
|
cmdlist.add_command('done', ['touch', os.path.join(installdir, 'ok')])
|
|
|
|
self.add_makefile_cmdlist('host-libraries', cmdlist, logsdir)
|
|
|
|
|
|
|
|
def build_host_library(self, cmdlist, lib, extra_opts=None):
|
|
|
|
"""Build one host library."""
|
|
|
|
srcdir = self.component_srcdir(lib)
|
|
|
|
builddir = self.component_builddir('host-libraries', None, lib)
|
|
|
|
installdir = self.host_libraries_installdir
|
|
|
|
cmdlist.push_subdesc(lib)
|
|
|
|
cmdlist.create_use_dir(builddir)
|
|
|
|
cfg_cmd = [os.path.join(srcdir, 'configure'),
|
|
|
|
'--prefix=%s' % installdir,
|
|
|
|
'--disable-shared']
|
|
|
|
if extra_opts:
|
|
|
|
cfg_cmd.extend (extra_opts)
|
|
|
|
cmdlist.add_command('configure', cfg_cmd)
|
|
|
|
cmdlist.add_command('build', ['make'])
|
|
|
|
cmdlist.add_command('check', ['make', 'check'])
|
|
|
|
cmdlist.add_command('install', ['make', 'install'])
|
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
cmdlist.pop_subdesc()
|
|
|
|
|
|
|
|
def build_compilers(self, configs):
|
|
|
|
"""Build the compilers."""
|
|
|
|
if not configs:
|
|
|
|
self.remove_dirs(os.path.join(self.builddir, 'compilers'))
|
|
|
|
self.remove_dirs(os.path.join(self.installdir, 'compilers'))
|
|
|
|
self.remove_dirs(os.path.join(self.logsdir, 'compilers'))
|
|
|
|
configs = sorted(self.configs.keys())
|
|
|
|
for c in configs:
|
|
|
|
self.configs[c].build()
|
|
|
|
|
|
|
|
def build_glibcs(self, configs):
|
|
|
|
"""Build the glibcs."""
|
|
|
|
if not configs:
|
|
|
|
self.remove_dirs(os.path.join(self.builddir, 'glibcs'))
|
|
|
|
self.remove_dirs(os.path.join(self.installdir, 'glibcs'))
|
|
|
|
self.remove_dirs(os.path.join(self.logsdir, 'glibcs'))
|
|
|
|
configs = sorted(self.glibc_configs.keys())
|
|
|
|
for c in configs:
|
|
|
|
self.glibc_configs[c].build()
|
|
|
|
|
2020-01-02 09:18:34 +00:00
|
|
|
def update_syscalls(self, configs):
|
|
|
|
"""Update the glibc syscall lists."""
|
|
|
|
if not configs:
|
|
|
|
self.remove_dirs(os.path.join(self.builddir, 'update-syscalls'))
|
|
|
|
self.remove_dirs(os.path.join(self.logsdir, 'update-syscalls'))
|
|
|
|
configs = sorted(self.glibc_configs.keys())
|
|
|
|
for c in configs:
|
|
|
|
self.glibc_configs[c].update_syscalls()
|
|
|
|
|
2016-11-24 22:25:58 +00:00
|
|
|
def load_versions_json(self):
|
|
|
|
"""Load information about source directory versions."""
|
|
|
|
if not os.access(self.versions_json, os.F_OK):
|
|
|
|
self.versions = {}
|
|
|
|
return
|
|
|
|
with open(self.versions_json, 'r') as f:
|
|
|
|
self.versions = json.load(f)
|
|
|
|
|
|
|
|
def store_json(self, data, filename):
|
|
|
|
"""Store information in a JSON file."""
|
|
|
|
filename_tmp = filename + '.tmp'
|
|
|
|
with open(filename_tmp, 'w') as f:
|
|
|
|
json.dump(data, f, indent=2, sort_keys=True)
|
|
|
|
os.rename(filename_tmp, filename)
|
|
|
|
|
|
|
|
def store_versions_json(self):
|
|
|
|
"""Store information about source directory versions."""
|
|
|
|
self.store_json(self.versions, self.versions_json)
|
|
|
|
|
|
|
|
def set_component_version(self, component, version, explicit, revision):
|
|
|
|
"""Set the version information for a component."""
|
|
|
|
self.versions[component] = {'version': version,
|
|
|
|
'explicit': explicit,
|
|
|
|
'revision': revision}
|
|
|
|
self.store_versions_json()
|
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
def checkout(self, versions):
|
|
|
|
"""Check out the desired component versions."""
|
2024-01-30 14:20:35 +00:00
|
|
|
default_versions = {'binutils': 'vcs-2.42',
|
2023-05-02 13:57:58 +00:00
|
|
|
'gcc': 'vcs-13',
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'glibc': 'vcs-mainline',
|
2023-08-29 14:11:35 +00:00
|
|
|
'gmp': '6.3.0',
|
2024-01-17 11:35:35 +00:00
|
|
|
'linux': '6.7',
|
2023-01-27 18:27:26 +00:00
|
|
|
'mpc': '1.3.1',
|
2023-08-29 14:11:35 +00:00
|
|
|
'mpfr': '4.2.1',
|
2018-01-27 20:44:57 +00:00
|
|
|
'mig': 'vcs-mainline',
|
2018-01-28 14:48:04 +00:00
|
|
|
'gnumach': 'vcs-mainline',
|
2018-01-26 01:35:10 +00:00
|
|
|
'hurd': 'vcs-mainline'}
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
use_versions = {}
|
2016-11-24 22:25:58 +00:00
|
|
|
explicit_versions = {}
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
for v in versions:
|
|
|
|
found_v = False
|
|
|
|
for k in default_versions.keys():
|
|
|
|
kx = k + '-'
|
|
|
|
if v.startswith(kx):
|
|
|
|
vx = v[len(kx):]
|
|
|
|
if k in use_versions:
|
|
|
|
print('error: multiple versions for %s' % k)
|
|
|
|
exit(1)
|
|
|
|
use_versions[k] = vx
|
2016-11-24 22:25:58 +00:00
|
|
|
explicit_versions[k] = True
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
found_v = True
|
|
|
|
break
|
|
|
|
if not found_v:
|
|
|
|
print('error: unknown component in %s' % v)
|
|
|
|
exit(1)
|
|
|
|
for k in default_versions.keys():
|
|
|
|
if k not in use_versions:
|
2016-11-24 22:25:58 +00:00
|
|
|
if k in self.versions and self.versions[k]['explicit']:
|
|
|
|
use_versions[k] = self.versions[k]['version']
|
|
|
|
explicit_versions[k] = True
|
|
|
|
else:
|
|
|
|
use_versions[k] = default_versions[k]
|
|
|
|
explicit_versions[k] = False
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
os.makedirs(self.srcdir, exist_ok=True)
|
|
|
|
for k in sorted(default_versions.keys()):
|
|
|
|
update = os.access(self.component_srcdir(k), os.F_OK)
|
|
|
|
v = use_versions[k]
|
2016-11-24 22:25:58 +00:00
|
|
|
if (update and
|
|
|
|
k in self.versions and
|
|
|
|
v != self.versions[k]['version']):
|
|
|
|
if not self.replace_sources:
|
|
|
|
print('error: version of %s has changed from %s to %s, '
|
|
|
|
'use --replace-sources to check out again' %
|
|
|
|
(k, self.versions[k]['version'], v))
|
|
|
|
exit(1)
|
|
|
|
shutil.rmtree(self.component_srcdir(k))
|
|
|
|
update = False
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if v.startswith('vcs-'):
|
2016-11-24 22:25:58 +00:00
|
|
|
revision = self.checkout_vcs(k, v[4:], update)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
else:
|
|
|
|
self.checkout_tar(k, v, update)
|
2016-11-24 22:25:58 +00:00
|
|
|
revision = v
|
|
|
|
self.set_component_version(k, v, explicit_versions[k], revision)
|
2016-11-25 00:58:22 +00:00
|
|
|
if self.get_script_text() != self.script_text:
|
|
|
|
# Rerun the checkout process in case the updated script
|
|
|
|
# uses different default versions or new components.
|
|
|
|
self.exec_self()
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def checkout_vcs(self, component, version, update):
|
|
|
|
"""Check out the given version of the given component from version
|
2016-11-24 22:25:58 +00:00
|
|
|
control. Return a revision identifier."""
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if component == 'binutils':
|
2022-09-05 13:51:05 +00:00
|
|
|
git_url = 'https://sourceware.org/git/binutils-gdb.git'
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if version == 'mainline':
|
|
|
|
git_branch = 'master'
|
|
|
|
else:
|
|
|
|
trans = str.maketrans({'.': '_'})
|
|
|
|
git_branch = 'binutils-%s-branch' % version.translate(trans)
|
2016-11-24 22:25:58 +00:00
|
|
|
return self.git_checkout(component, git_url, git_branch, update)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
elif component == 'gcc':
|
|
|
|
if version == 'mainline':
|
2020-01-13 16:32:57 +00:00
|
|
|
branch = 'master'
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
else:
|
2020-01-13 16:32:57 +00:00
|
|
|
branch = 'releases/gcc-%s' % version
|
|
|
|
return self.gcc_checkout(branch, update)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
elif component == 'glibc':
|
2022-09-05 13:51:05 +00:00
|
|
|
git_url = 'https://sourceware.org/git/glibc.git'
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if version == 'mainline':
|
|
|
|
git_branch = 'master'
|
|
|
|
else:
|
|
|
|
git_branch = 'release/%s/master' % version
|
2016-11-24 22:25:58 +00:00
|
|
|
r = self.git_checkout(component, git_url, git_branch, update)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.fix_glibc_timestamps()
|
2016-11-24 22:25:58 +00:00
|
|
|
return r
|
2018-01-28 14:48:04 +00:00
|
|
|
elif component == 'gnumach':
|
|
|
|
git_url = 'git://git.savannah.gnu.org/hurd/gnumach.git'
|
|
|
|
git_branch = 'master'
|
|
|
|
r = self.git_checkout(component, git_url, git_branch, update)
|
|
|
|
subprocess.run(['autoreconf', '-i'],
|
|
|
|
cwd=self.component_srcdir(component), check=True)
|
|
|
|
return r
|
2018-01-27 20:44:57 +00:00
|
|
|
elif component == 'mig':
|
|
|
|
git_url = 'git://git.savannah.gnu.org/hurd/mig.git'
|
|
|
|
git_branch = 'master'
|
|
|
|
r = self.git_checkout(component, git_url, git_branch, update)
|
|
|
|
subprocess.run(['autoreconf', '-i'],
|
|
|
|
cwd=self.component_srcdir(component), check=True)
|
|
|
|
return r
|
2018-01-25 02:01:59 +00:00
|
|
|
elif component == 'hurd':
|
|
|
|
git_url = 'git://git.savannah.gnu.org/hurd/hurd.git'
|
|
|
|
git_branch = 'master'
|
2018-01-25 02:14:22 +00:00
|
|
|
r = self.git_checkout(component, git_url, git_branch, update)
|
|
|
|
subprocess.run(['autoconf'],
|
|
|
|
cwd=self.component_srcdir(component), check=True)
|
|
|
|
return r
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
else:
|
|
|
|
print('error: component %s coming from VCS' % component)
|
|
|
|
exit(1)
|
|
|
|
|
|
|
|
def git_checkout(self, component, git_url, git_branch, update):
|
2016-11-24 22:25:58 +00:00
|
|
|
"""Check out a component from git. Return a commit identifier."""
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if update:
|
|
|
|
subprocess.run(['git', 'remote', 'prune', 'origin'],
|
|
|
|
cwd=self.component_srcdir(component), check=True)
|
2018-01-29 13:59:33 +00:00
|
|
|
if self.replace_sources:
|
|
|
|
subprocess.run(['git', 'clean', '-dxfq'],
|
|
|
|
cwd=self.component_srcdir(component), check=True)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
subprocess.run(['git', 'pull', '-q'],
|
|
|
|
cwd=self.component_srcdir(component), check=True)
|
|
|
|
else:
|
2020-02-28 11:32:28 +00:00
|
|
|
if self.shallow:
|
|
|
|
depth_arg = ('--depth', '1')
|
|
|
|
else:
|
|
|
|
depth_arg = ()
|
|
|
|
subprocess.run(['git', 'clone', '-q', '-b', git_branch,
|
|
|
|
*depth_arg, git_url,
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.component_srcdir(component)], check=True)
|
2016-11-24 22:25:58 +00:00
|
|
|
r = subprocess.run(['git', 'rev-parse', 'HEAD'],
|
|
|
|
cwd=self.component_srcdir(component),
|
|
|
|
stdout=subprocess.PIPE,
|
|
|
|
check=True, universal_newlines=True).stdout
|
|
|
|
return r.rstrip()
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def fix_glibc_timestamps(self):
|
|
|
|
"""Fix timestamps in a glibc checkout."""
|
|
|
|
# Ensure that builds do not try to regenerate generated files
|
|
|
|
# in the source tree.
|
|
|
|
srcdir = self.component_srcdir('glibc')
|
2018-11-26 23:52:43 +00:00
|
|
|
# These files have Makefile dependencies to regenerate them in
|
|
|
|
# the source tree that may be active during a normal build.
|
|
|
|
# Some other files have such dependencies but do not need to
|
|
|
|
# be touched because nothing in a build depends on the files
|
|
|
|
# in question.
|
2020-04-25 00:25:31 +00:00
|
|
|
for f in ('sysdeps/mach/hurd/bits/errno.h',):
|
2018-11-26 23:52:43 +00:00
|
|
|
to_touch = os.path.join(srcdir, f)
|
|
|
|
subprocess.run(['touch', '-c', to_touch], check=True)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
for dirpath, dirnames, filenames in os.walk(srcdir):
|
|
|
|
for f in filenames:
|
|
|
|
if (f == 'configure' or
|
|
|
|
f == 'preconfigure' or
|
|
|
|
f.endswith('-kw.h')):
|
|
|
|
to_touch = os.path.join(dirpath, f)
|
|
|
|
subprocess.run(['touch', to_touch], check=True)
|
|
|
|
|
2020-01-13 16:32:57 +00:00
|
|
|
def gcc_checkout(self, branch, update):
|
|
|
|
"""Check out GCC from git. Return the commit identifier."""
|
|
|
|
if os.access(os.path.join(self.component_srcdir('gcc'), '.svn'),
|
|
|
|
os.F_OK):
|
|
|
|
if not self.replace_sources:
|
|
|
|
print('error: GCC has moved from SVN to git, use '
|
|
|
|
'--replace-sources to check out again')
|
|
|
|
exit(1)
|
|
|
|
shutil.rmtree(self.component_srcdir('gcc'))
|
|
|
|
update = False
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if not update:
|
2022-09-05 13:51:05 +00:00
|
|
|
self.git_checkout('gcc', 'https://gcc.gnu.org/git/gcc.git',
|
2020-01-13 16:32:57 +00:00
|
|
|
branch, update)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
subprocess.run(['contrib/gcc_update', '--silent'],
|
|
|
|
cwd=self.component_srcdir('gcc'), check=True)
|
2020-01-13 16:32:57 +00:00
|
|
|
r = subprocess.run(['git', 'rev-parse', 'HEAD'],
|
|
|
|
cwd=self.component_srcdir('gcc'),
|
2016-11-24 22:25:58 +00:00
|
|
|
stdout=subprocess.PIPE,
|
|
|
|
check=True, universal_newlines=True).stdout
|
|
|
|
return r.rstrip()
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def checkout_tar(self, component, version, update):
|
|
|
|
"""Check out the given version of the given component from a
|
|
|
|
tarball."""
|
|
|
|
if update:
|
|
|
|
return
|
|
|
|
url_map = {'binutils': 'https://ftp.gnu.org/gnu/binutils/binutils-%(version)s.tar.bz2',
|
2018-07-20 15:30:05 +00:00
|
|
|
'gcc': 'https://ftp.gnu.org/gnu/gcc/gcc-%(version)s/gcc-%(version)s.tar.gz',
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'gmp': 'https://ftp.gnu.org/gnu/gmp/gmp-%(version)s.tar.xz',
|
2019-03-13 22:03:37 +00:00
|
|
|
'linux': 'https://www.kernel.org/pub/linux/kernel/v%(major)s.x/linux-%(version)s.tar.xz',
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'mpc': 'https://ftp.gnu.org/gnu/mpc/mpc-%(version)s.tar.gz',
|
2018-01-24 01:18:54 +00:00
|
|
|
'mpfr': 'https://ftp.gnu.org/gnu/mpfr/mpfr-%(version)s.tar.xz',
|
|
|
|
'mig': 'https://ftp.gnu.org/gnu/mig/mig-%(version)s.tar.bz2',
|
|
|
|
'gnumach': 'https://ftp.gnu.org/gnu/gnumach/gnumach-%(version)s.tar.bz2',
|
|
|
|
'hurd': 'https://ftp.gnu.org/gnu/hurd/hurd-%(version)s.tar.bz2'}
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if component not in url_map:
|
|
|
|
print('error: component %s coming from tarball' % component)
|
|
|
|
exit(1)
|
2019-03-13 22:03:37 +00:00
|
|
|
version_major = version.split('.')[0]
|
|
|
|
url = url_map[component] % {'version': version, 'major': version_major}
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
filename = os.path.join(self.srcdir, url.split('/')[-1])
|
|
|
|
response = urllib.request.urlopen(url)
|
|
|
|
data = response.read()
|
|
|
|
with open(filename, 'wb') as f:
|
|
|
|
f.write(data)
|
|
|
|
subprocess.run(['tar', '-C', self.srcdir, '-x', '-f', filename],
|
|
|
|
check=True)
|
|
|
|
os.rename(os.path.join(self.srcdir, '%s-%s' % (component, version)),
|
|
|
|
self.component_srcdir(component))
|
|
|
|
os.remove(filename)
|
|
|
|
|
2016-11-26 00:10:24 +00:00
|
|
|
def load_build_state_json(self):
|
|
|
|
"""Load information about the state of previous builds."""
|
|
|
|
if os.access(self.build_state_json, os.F_OK):
|
|
|
|
with open(self.build_state_json, 'r') as f:
|
|
|
|
self.build_state = json.load(f)
|
|
|
|
else:
|
|
|
|
self.build_state = {}
|
2020-01-02 09:18:34 +00:00
|
|
|
for k in ('host-libraries', 'compilers', 'glibcs', 'update-syscalls'):
|
2016-11-26 00:10:24 +00:00
|
|
|
if k not in self.build_state:
|
|
|
|
self.build_state[k] = {}
|
|
|
|
if 'build-time' not in self.build_state[k]:
|
|
|
|
self.build_state[k]['build-time'] = ''
|
|
|
|
if 'build-versions' not in self.build_state[k]:
|
|
|
|
self.build_state[k]['build-versions'] = {}
|
|
|
|
if 'build-results' not in self.build_state[k]:
|
|
|
|
self.build_state[k]['build-results'] = {}
|
|
|
|
if 'result-changes' not in self.build_state[k]:
|
|
|
|
self.build_state[k]['result-changes'] = {}
|
|
|
|
if 'ever-passed' not in self.build_state[k]:
|
|
|
|
self.build_state[k]['ever-passed'] = []
|
|
|
|
|
|
|
|
def store_build_state_json(self):
|
|
|
|
"""Store information about the state of previous builds."""
|
|
|
|
self.store_json(self.build_state, self.build_state_json)
|
|
|
|
|
|
|
|
def clear_last_build_state(self, action):
|
|
|
|
"""Clear information about the state of part of the build."""
|
|
|
|
# We clear the last build time and versions when starting a
|
|
|
|
# new build. The results of the last build are kept around,
|
|
|
|
# as comparison is still meaningful if this build is aborted
|
|
|
|
# and a new one started.
|
|
|
|
self.build_state[action]['build-time'] = ''
|
|
|
|
self.build_state[action]['build-versions'] = {}
|
|
|
|
self.store_build_state_json()
|
|
|
|
|
|
|
|
def update_build_state(self, action, build_time, build_versions):
|
|
|
|
"""Update the build state after a build."""
|
|
|
|
build_time = build_time.replace(microsecond=0)
|
2024-01-19 13:30:34 +00:00
|
|
|
self.build_state[action]['build-time'] = build_time.strftime(
|
|
|
|
'%Y-%m-%d %H:%M:%S')
|
2016-11-26 00:10:24 +00:00
|
|
|
self.build_state[action]['build-versions'] = build_versions
|
|
|
|
build_results = {}
|
|
|
|
for log in self.status_log_list:
|
|
|
|
with open(log, 'r') as f:
|
|
|
|
log_text = f.read()
|
|
|
|
log_text = log_text.rstrip()
|
|
|
|
m = re.fullmatch('([A-Z]+): (.*)', log_text)
|
|
|
|
result = m.group(1)
|
|
|
|
test_name = m.group(2)
|
|
|
|
assert test_name not in build_results
|
|
|
|
build_results[test_name] = result
|
|
|
|
old_build_results = self.build_state[action]['build-results']
|
|
|
|
self.build_state[action]['build-results'] = build_results
|
|
|
|
result_changes = {}
|
|
|
|
all_tests = set(old_build_results.keys()) | set(build_results.keys())
|
|
|
|
for t in all_tests:
|
|
|
|
if t in old_build_results:
|
|
|
|
old_res = old_build_results[t]
|
|
|
|
else:
|
|
|
|
old_res = '(New test)'
|
|
|
|
if t in build_results:
|
|
|
|
new_res = build_results[t]
|
|
|
|
else:
|
|
|
|
new_res = '(Test removed)'
|
|
|
|
if old_res != new_res:
|
|
|
|
result_changes[t] = '%s -> %s' % (old_res, new_res)
|
|
|
|
self.build_state[action]['result-changes'] = result_changes
|
|
|
|
old_ever_passed = {t for t in self.build_state[action]['ever-passed']
|
|
|
|
if t in build_results}
|
|
|
|
new_passes = {t for t in build_results if build_results[t] == 'PASS'}
|
|
|
|
self.build_state[action]['ever-passed'] = sorted(old_ever_passed |
|
|
|
|
new_passes)
|
|
|
|
self.store_build_state_json()
|
|
|
|
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
def load_bot_config_json(self):
|
|
|
|
"""Load bot configuration."""
|
|
|
|
with open(self.bot_config_json, 'r') as f:
|
|
|
|
self.bot_config = json.load(f)
|
|
|
|
|
|
|
|
def part_build_old(self, action, delay):
|
|
|
|
"""Return whether the last build for a given action was at least a
|
|
|
|
given number of seconds ago, or does not have a time recorded."""
|
|
|
|
old_time_str = self.build_state[action]['build-time']
|
|
|
|
if not old_time_str:
|
|
|
|
return True
|
2024-01-19 13:30:34 +00:00
|
|
|
old_time = datetime.datetime.strptime(
|
|
|
|
old_time_str, '%Y-%m-%d %H:%M:%S').replace(
|
|
|
|
tzinfo=datetime.timezone.utc)
|
|
|
|
new_time = datetime.datetime.now(datetime.timezone.utc)
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
delta = new_time - old_time
|
|
|
|
return delta.total_seconds() >= delay
|
|
|
|
|
|
|
|
def bot_cycle(self):
|
|
|
|
"""Run a single round of checkout and builds."""
|
2024-01-19 13:30:34 +00:00
|
|
|
print('Bot cycle starting %s.'
|
|
|
|
% str(datetime.datetime.now(datetime.timezone.utc)))
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
self.load_bot_config_json()
|
|
|
|
actions = ('host-libraries', 'compilers', 'glibcs')
|
|
|
|
self.bot_run_self(['--replace-sources'], 'checkout')
|
|
|
|
self.load_versions_json()
|
|
|
|
if self.get_script_text() != self.script_text:
|
|
|
|
print('Script changed, re-execing.')
|
|
|
|
# On script change, all parts of the build should be rerun.
|
|
|
|
for a in actions:
|
|
|
|
self.clear_last_build_state(a)
|
|
|
|
self.exec_self()
|
|
|
|
check_components = {'host-libraries': ('gmp', 'mpfr', 'mpc'),
|
2018-01-24 01:18:54 +00:00
|
|
|
'compilers': ('binutils', 'gcc', 'glibc', 'linux',
|
|
|
|
'mig', 'gnumach', 'hurd'),
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
'glibcs': ('glibc',)}
|
|
|
|
must_build = {}
|
|
|
|
for a in actions:
|
|
|
|
build_vers = self.build_state[a]['build-versions']
|
|
|
|
must_build[a] = False
|
|
|
|
if not self.build_state[a]['build-time']:
|
|
|
|
must_build[a] = True
|
|
|
|
old_vers = {}
|
|
|
|
new_vers = {}
|
|
|
|
for c in check_components[a]:
|
|
|
|
if c in build_vers:
|
|
|
|
old_vers[c] = build_vers[c]
|
|
|
|
new_vers[c] = {'version': self.versions[c]['version'],
|
|
|
|
'revision': self.versions[c]['revision']}
|
|
|
|
if new_vers == old_vers:
|
|
|
|
print('Versions for %s unchanged.' % a)
|
|
|
|
else:
|
|
|
|
print('Versions changed or rebuild forced for %s.' % a)
|
|
|
|
if a == 'compilers' and not self.part_build_old(
|
|
|
|
a, self.bot_config['compilers-rebuild-delay']):
|
|
|
|
print('Not requiring rebuild of compilers this soon.')
|
|
|
|
else:
|
|
|
|
must_build[a] = True
|
|
|
|
if must_build['host-libraries']:
|
|
|
|
must_build['compilers'] = True
|
|
|
|
if must_build['compilers']:
|
|
|
|
must_build['glibcs'] = True
|
|
|
|
for a in actions:
|
|
|
|
if must_build[a]:
|
|
|
|
print('Must rebuild %s.' % a)
|
|
|
|
self.clear_last_build_state(a)
|
|
|
|
else:
|
|
|
|
print('No need to rebuild %s.' % a)
|
2016-12-01 00:09:25 +00:00
|
|
|
if os.access(self.logsdir, os.F_OK):
|
|
|
|
shutil.rmtree(self.logsdir_old, ignore_errors=True)
|
|
|
|
shutil.copytree(self.logsdir, self.logsdir_old)
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
for a in actions:
|
|
|
|
if must_build[a]:
|
2024-01-19 13:30:34 +00:00
|
|
|
build_time = datetime.datetime.now(datetime.timezone.utc)
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
print('Rebuilding %s at %s.' % (a, str(build_time)))
|
|
|
|
self.bot_run_self([], a)
|
|
|
|
self.load_build_state_json()
|
|
|
|
self.bot_build_mail(a, build_time)
|
2024-01-19 13:30:34 +00:00
|
|
|
print('Bot cycle done at %s.'
|
|
|
|
% str(datetime.datetime.now(datetime.timezone.utc)))
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
|
|
|
|
def bot_build_mail(self, action, build_time):
|
|
|
|
"""Send email with the results of a build."""
|
2017-02-16 21:57:35 +00:00
|
|
|
if not ('email-from' in self.bot_config and
|
|
|
|
'email-server' in self.bot_config and
|
|
|
|
'email-subject' in self.bot_config and
|
|
|
|
'email-to' in self.bot_config):
|
|
|
|
if not self.email_warning:
|
|
|
|
print("Email not configured, not sending.")
|
|
|
|
self.email_warning = True
|
|
|
|
return
|
|
|
|
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
build_time = build_time.replace(microsecond=0)
|
|
|
|
subject = (self.bot_config['email-subject'] %
|
|
|
|
{'action': action,
|
2024-01-19 13:30:34 +00:00
|
|
|
'build-time': build_time.strftime('%Y-%m-%d %H:%M:%S')})
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
results = self.build_state[action]['build-results']
|
|
|
|
changes = self.build_state[action]['result-changes']
|
|
|
|
ever_passed = set(self.build_state[action]['ever-passed'])
|
|
|
|
versions = self.build_state[action]['build-versions']
|
|
|
|
new_regressions = {k for k in changes if changes[k] == 'PASS -> FAIL'}
|
|
|
|
all_regressions = {k for k in ever_passed if results[k] == 'FAIL'}
|
|
|
|
all_fails = {k for k in results if results[k] == 'FAIL'}
|
|
|
|
if new_regressions:
|
|
|
|
new_reg_list = sorted(['FAIL: %s' % k for k in new_regressions])
|
|
|
|
new_reg_text = ('New regressions:\n\n%s\n\n' %
|
|
|
|
'\n'.join(new_reg_list))
|
|
|
|
else:
|
|
|
|
new_reg_text = ''
|
|
|
|
if all_regressions:
|
|
|
|
all_reg_list = sorted(['FAIL: %s' % k for k in all_regressions])
|
|
|
|
all_reg_text = ('All regressions:\n\n%s\n\n' %
|
|
|
|
'\n'.join(all_reg_list))
|
|
|
|
else:
|
|
|
|
all_reg_text = ''
|
|
|
|
if all_fails:
|
|
|
|
all_fail_list = sorted(['FAIL: %s' % k for k in all_fails])
|
|
|
|
all_fail_text = ('All failures:\n\n%s\n\n' %
|
|
|
|
'\n'.join(all_fail_list))
|
|
|
|
else:
|
|
|
|
all_fail_text = ''
|
|
|
|
if changes:
|
|
|
|
changes_list = sorted(changes.keys())
|
|
|
|
changes_list = ['%s: %s' % (changes[k], k) for k in changes_list]
|
|
|
|
changes_text = ('All changed results:\n\n%s\n\n' %
|
|
|
|
'\n'.join(changes_list))
|
|
|
|
else:
|
|
|
|
changes_text = ''
|
|
|
|
results_text = (new_reg_text + all_reg_text + all_fail_text +
|
|
|
|
changes_text)
|
|
|
|
if not results_text:
|
|
|
|
results_text = 'Clean build with unchanged results.\n\n'
|
|
|
|
versions_list = sorted(versions.keys())
|
|
|
|
versions_list = ['%s: %s (%s)' % (k, versions[k]['version'],
|
|
|
|
versions[k]['revision'])
|
|
|
|
for k in versions_list]
|
|
|
|
versions_text = ('Component versions for this build:\n\n%s\n' %
|
|
|
|
'\n'.join(versions_list))
|
|
|
|
body_text = results_text + versions_text
|
|
|
|
msg = email.mime.text.MIMEText(body_text)
|
|
|
|
msg['Subject'] = subject
|
|
|
|
msg['From'] = self.bot_config['email-from']
|
|
|
|
msg['To'] = self.bot_config['email-to']
|
|
|
|
msg['Message-ID'] = email.utils.make_msgid()
|
2024-01-19 13:30:34 +00:00
|
|
|
msg['Date'] = email.utils.format_datetime(
|
|
|
|
datetime.datetime.now(datetime.timezone.utc))
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
with smtplib.SMTP(self.bot_config['email-server']) as s:
|
|
|
|
s.send_message(msg)
|
|
|
|
|
2016-12-01 00:09:25 +00:00
|
|
|
def bot_run_self(self, opts, action, check=True):
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
"""Run a copy of this script with given options."""
|
|
|
|
cmd = [sys.executable, sys.argv[0], '--keep=none',
|
|
|
|
'-j%d' % self.parallelism]
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
if self.full_gcc:
|
|
|
|
cmd.append('--full-gcc')
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
cmd.extend(opts)
|
|
|
|
cmd.extend([self.topdir, action])
|
2016-12-01 00:09:25 +00:00
|
|
|
sys.stdout.flush()
|
|
|
|
subprocess.run(cmd, check=check)
|
|
|
|
|
|
|
|
def bot(self):
|
|
|
|
"""Run repeated rounds of checkout and builds."""
|
|
|
|
while True:
|
|
|
|
self.load_bot_config_json()
|
|
|
|
if not self.bot_config['run']:
|
|
|
|
print('Bot exiting by request.')
|
|
|
|
exit(0)
|
|
|
|
self.bot_run_self([], 'bot-cycle', check=False)
|
|
|
|
self.load_bot_config_json()
|
|
|
|
if not self.bot_config['run']:
|
|
|
|
print('Bot exiting by request.')
|
|
|
|
exit(0)
|
|
|
|
time.sleep(self.bot_config['delay'])
|
|
|
|
if self.get_script_text() != self.script_text:
|
|
|
|
print('Script changed, bot re-execing.')
|
|
|
|
self.exec_self()
|
Add build-many-glibcs.py bot-cycle action.
This patch continues the process of setting up build-many-glibcs.py to
run as a bot monitoring for and reporting on build issues by adding a
bot-cycle action to the script. When this action is used, it will run
the checkout action (re-execing itself if it was changed by that
action), then rebuild whichever of host-libraries, compilers, glibcs
should be rebuilt based on changed versions, time elapsed and state of
previous builds. Email is sent with the results of the build (for
each build action done).
The rebuild logic is: if previous build time or versions aren't
recorded, rebuild that component. If the script has changed, rebuild
everything. If any relevant component version has changed, rebuild,
except for not rebuilding compilers if the time indicated in the bot
configuration has not passed since the last build of the compilers.
If one piece is rebuilt then rebuild subsequent pieces as well.
Using bot-cycle requires a configuration file bot-config.json in the
toplevel directory used by build-many-glibcs.py. It might contain
e.g.
{
"compilers-rebuild-delay": 604800,
"email-from": "Example Name <user@example.org>",
"email-server": "localhost",
"email-subject": "GCC 6 %(action)s %(build-time)s build results",
"email-to": "libc-testresults@sourceware.org"
}
My next intended step is adding a further action "bot" which loops
running bot-cycle then sleeping for an amount of time given in
bot-config.json. Then I'll set up a bot using that action (building
with GCC 6 branch; a bot using GCC mainline may wait until the SH
out-of-memory issues
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460> are fixed; I
expect the bot to mail to me until it seems ready to switch to mailing
to gcc-testresults).
* scripts/build-many-glibcs.py: Add bot-cycle to usage message.
Import email.mime.text, email.utils and smtplib modules.
(Context.__init__): Initialize self.bot_config_json.
(Context.run_builds): Handle bot-cycle action.
(Context.load_bot_config_json): New function.
(Context.part_build_old): Likewise.
(Context.bot_cycle): Likewise.
(Context.bot_build_mail): Likewise.
(Context.bot_run_self): Likewise.
(get_parser): Allow bot-cycle action.
2016-11-30 18:56:37 +00:00
|
|
|
|
2020-01-02 09:18:26 +00:00
|
|
|
class LinuxHeadersPolicyForBuild(object):
|
|
|
|
"""Names and directories for installing Linux headers. Build variant."""
|
|
|
|
|
|
|
|
def __init__(self, config):
|
|
|
|
self.arch = config.arch
|
|
|
|
self.srcdir = config.ctx.component_srcdir('linux')
|
|
|
|
self.builddir = config.component_builddir('linux')
|
|
|
|
self.headers_dir = os.path.join(config.sysroot, 'usr')
|
|
|
|
|
2020-01-02 09:18:34 +00:00
|
|
|
class LinuxHeadersPolicyForUpdateSyscalls(object):
|
|
|
|
"""Names and directories for Linux headers. update-syscalls variant."""
|
|
|
|
|
|
|
|
def __init__(self, glibc, headers_dir):
|
|
|
|
self.arch = glibc.compiler.arch
|
|
|
|
self.srcdir = glibc.compiler.ctx.component_srcdir('linux')
|
|
|
|
self.builddir = glibc.ctx.component_builddir(
|
|
|
|
'update-syscalls', glibc.name, 'build-linux')
|
|
|
|
self.headers_dir = headers_dir
|
|
|
|
|
2020-01-02 09:18:26 +00:00
|
|
|
def install_linux_headers(policy, cmdlist):
|
|
|
|
"""Install Linux kernel headers."""
|
|
|
|
arch_map = {'aarch64': 'arm64',
|
|
|
|
'alpha': 'alpha',
|
2020-03-13 01:29:59 +00:00
|
|
|
'arc': 'arc',
|
2020-01-02 09:18:26 +00:00
|
|
|
'arm': 'arm',
|
|
|
|
'csky': 'csky',
|
|
|
|
'hppa': 'parisc',
|
|
|
|
'i486': 'x86',
|
|
|
|
'i586': 'x86',
|
|
|
|
'i686': 'x86',
|
|
|
|
'i786': 'x86',
|
2022-07-19 01:22:09 +00:00
|
|
|
'loongarch64': 'loongarch',
|
2020-01-02 09:18:26 +00:00
|
|
|
'm68k': 'm68k',
|
|
|
|
'microblaze': 'microblaze',
|
|
|
|
'mips': 'mips',
|
|
|
|
'nios2': 'nios2',
|
2021-10-19 21:54:48 +00:00
|
|
|
'or1k': 'openrisc',
|
2020-01-02 09:18:26 +00:00
|
|
|
'powerpc': 'powerpc',
|
|
|
|
's390': 's390',
|
|
|
|
'riscv32': 'riscv',
|
|
|
|
'riscv64': 'riscv',
|
|
|
|
'sh': 'sh',
|
|
|
|
'sparc': 'sparc',
|
|
|
|
'x86_64': 'x86'}
|
|
|
|
linux_arch = None
|
|
|
|
for k in arch_map:
|
|
|
|
if policy.arch.startswith(k):
|
|
|
|
linux_arch = arch_map[k]
|
|
|
|
break
|
|
|
|
assert linux_arch is not None
|
|
|
|
cmdlist.push_subdesc('linux')
|
|
|
|
cmdlist.create_use_dir(policy.builddir)
|
|
|
|
cmdlist.add_command('install-headers',
|
|
|
|
['make', '-C', policy.srcdir, 'O=%s' % policy.builddir,
|
|
|
|
'ARCH=%s' % linux_arch,
|
|
|
|
'INSTALL_HDR_PATH=%s' % policy.headers_dir,
|
|
|
|
'headers_install'])
|
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
cmdlist.pop_subdesc()
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
2016-11-14 23:48:50 +00:00
|
|
|
class Config(object):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""A configuration for building a compiler and associated libraries."""
|
|
|
|
|
|
|
|
def __init__(self, ctx, arch, os_name, variant=None, gcc_cfg=None,
|
2020-08-13 18:51:10 +00:00
|
|
|
first_gcc_cfg=None, binutils_cfg=None, glibcs=None,
|
|
|
|
extra_glibcs=None):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""Initialize a Config object."""
|
|
|
|
self.ctx = ctx
|
|
|
|
self.arch = arch
|
|
|
|
self.os = os_name
|
|
|
|
self.variant = variant
|
|
|
|
if variant is None:
|
|
|
|
self.name = '%s-%s' % (arch, os_name)
|
|
|
|
else:
|
|
|
|
self.name = '%s-%s-%s' % (arch, os_name, variant)
|
|
|
|
self.triplet = '%s-glibc-%s' % (arch, os_name)
|
|
|
|
if gcc_cfg is None:
|
|
|
|
self.gcc_cfg = []
|
|
|
|
else:
|
|
|
|
self.gcc_cfg = gcc_cfg
|
|
|
|
if first_gcc_cfg is None:
|
|
|
|
self.first_gcc_cfg = []
|
|
|
|
else:
|
|
|
|
self.first_gcc_cfg = first_gcc_cfg
|
2020-08-13 18:51:10 +00:00
|
|
|
if binutils_cfg is None:
|
|
|
|
self.binutils_cfg = []
|
|
|
|
else:
|
|
|
|
self.binutils_cfg = binutils_cfg
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if glibcs is None:
|
|
|
|
glibcs = [{'variant': variant}]
|
|
|
|
if extra_glibcs is None:
|
|
|
|
extra_glibcs = []
|
|
|
|
glibcs = [Glibc(self, **g) for g in glibcs]
|
|
|
|
extra_glibcs = [Glibc(self, **g) for g in extra_glibcs]
|
|
|
|
self.all_glibcs = glibcs + extra_glibcs
|
|
|
|
self.compiler_glibcs = glibcs
|
|
|
|
self.installdir = ctx.compiler_installdir(self.name)
|
|
|
|
self.bindir = ctx.compiler_bindir(self.name)
|
|
|
|
self.sysroot = ctx.compiler_sysroot(self.name)
|
|
|
|
self.builddir = os.path.join(ctx.builddir, 'compilers', self.name)
|
|
|
|
self.logsdir = os.path.join(ctx.logsdir, 'compilers', self.name)
|
|
|
|
|
|
|
|
def component_builddir(self, component):
|
|
|
|
"""Return the directory to use for a (non-glibc) build."""
|
|
|
|
return self.ctx.component_builddir('compilers', self.name, component)
|
|
|
|
|
|
|
|
def build(self):
|
|
|
|
"""Generate commands to build this compiler."""
|
|
|
|
self.ctx.remove_recreate_dirs(self.installdir, self.builddir,
|
|
|
|
self.logsdir)
|
|
|
|
cmdlist = CommandList('compilers-%s' % self.name, self.ctx.keep)
|
|
|
|
cmdlist.add_command('check-host-libraries',
|
|
|
|
['test', '-f',
|
|
|
|
os.path.join(self.ctx.host_libraries_installdir,
|
|
|
|
'ok')])
|
|
|
|
cmdlist.use_path(self.bindir)
|
|
|
|
self.build_cross_tool(cmdlist, 'binutils', 'binutils',
|
|
|
|
['--disable-gdb',
|
2020-02-10 22:17:59 +00:00
|
|
|
'--disable-gdbserver',
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'--disable-libdecnumber',
|
|
|
|
'--disable-readline',
|
2020-08-13 18:51:10 +00:00
|
|
|
'--disable-sim'] + self.binutils_cfg)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if self.os.startswith('linux'):
|
2020-01-02 09:18:26 +00:00
|
|
|
install_linux_headers(LinuxHeadersPolicyForBuild(self), cmdlist)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.build_gcc(cmdlist, True)
|
2018-01-24 01:18:54 +00:00
|
|
|
if self.os == 'gnu':
|
|
|
|
self.install_gnumach_headers(cmdlist)
|
|
|
|
self.build_cross_tool(cmdlist, 'mig', 'mig')
|
|
|
|
self.install_hurd_headers(cmdlist)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
for g in self.compiler_glibcs:
|
|
|
|
cmdlist.push_subdesc('glibc')
|
|
|
|
cmdlist.push_subdesc(g.name)
|
2020-01-02 09:18:31 +00:00
|
|
|
g.build_glibc(cmdlist, GlibcPolicyForCompiler(g))
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
cmdlist.pop_subdesc()
|
|
|
|
cmdlist.pop_subdesc()
|
|
|
|
self.build_gcc(cmdlist, False)
|
|
|
|
cmdlist.add_command('done', ['touch',
|
|
|
|
os.path.join(self.installdir, 'ok')])
|
|
|
|
self.ctx.add_makefile_cmdlist('compilers-%s' % self.name, cmdlist,
|
|
|
|
self.logsdir)
|
|
|
|
|
|
|
|
def build_cross_tool(self, cmdlist, tool_src, tool_build, extra_opts=None):
|
|
|
|
"""Build one cross tool."""
|
|
|
|
srcdir = self.ctx.component_srcdir(tool_src)
|
|
|
|
builddir = self.component_builddir(tool_build)
|
|
|
|
cmdlist.push_subdesc(tool_build)
|
|
|
|
cmdlist.create_use_dir(builddir)
|
|
|
|
cfg_cmd = [os.path.join(srcdir, 'configure'),
|
|
|
|
'--prefix=%s' % self.installdir,
|
|
|
|
'--build=%s' % self.ctx.build_triplet,
|
|
|
|
'--host=%s' % self.ctx.build_triplet,
|
|
|
|
'--target=%s' % self.triplet,
|
|
|
|
'--with-sysroot=%s' % self.sysroot]
|
|
|
|
if extra_opts:
|
|
|
|
cfg_cmd.extend(extra_opts)
|
|
|
|
cmdlist.add_command('configure', cfg_cmd)
|
|
|
|
cmdlist.add_command('build', ['make'])
|
2017-01-18 23:13:09 +00:00
|
|
|
# Parallel "make install" for GCC has race conditions that can
|
|
|
|
# cause it to fail; see
|
|
|
|
# <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980>. Such
|
|
|
|
# problems are not known for binutils, but doing the
|
|
|
|
# installation in parallel within a particular toolchain build
|
|
|
|
# (as opposed to installation of one toolchain from
|
|
|
|
# build-many-glibcs.py running in parallel to the installation
|
|
|
|
# of other toolchains being built) is not known to be
|
|
|
|
# significantly beneficial, so it is simplest just to disable
|
|
|
|
# parallel install for cross tools here.
|
|
|
|
cmdlist.add_command('install', ['make', '-j1', 'install'])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
cmdlist.pop_subdesc()
|
|
|
|
|
2018-01-24 01:18:54 +00:00
|
|
|
def install_gnumach_headers(self, cmdlist):
|
|
|
|
"""Install GNU Mach headers."""
|
|
|
|
srcdir = self.ctx.component_srcdir('gnumach')
|
|
|
|
builddir = self.component_builddir('gnumach')
|
|
|
|
cmdlist.push_subdesc('gnumach')
|
|
|
|
cmdlist.create_use_dir(builddir)
|
|
|
|
cmdlist.add_command('configure',
|
|
|
|
[os.path.join(srcdir, 'configure'),
|
|
|
|
'--build=%s' % self.ctx.build_triplet,
|
|
|
|
'--host=%s' % self.triplet,
|
|
|
|
'--prefix=',
|
2023-05-01 00:20:59 +00:00
|
|
|
'--disable-user32',
|
2018-01-24 01:18:54 +00:00
|
|
|
'CC=%s-gcc -nostdlib' % self.triplet])
|
|
|
|
cmdlist.add_command('install', ['make', 'DESTDIR=%s' % self.sysroot,
|
|
|
|
'install-data'])
|
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
cmdlist.pop_subdesc()
|
|
|
|
|
|
|
|
def install_hurd_headers(self, cmdlist):
|
|
|
|
"""Install Hurd headers."""
|
|
|
|
srcdir = self.ctx.component_srcdir('hurd')
|
|
|
|
builddir = self.component_builddir('hurd')
|
|
|
|
cmdlist.push_subdesc('hurd')
|
|
|
|
cmdlist.create_use_dir(builddir)
|
|
|
|
cmdlist.add_command('configure',
|
|
|
|
[os.path.join(srcdir, 'configure'),
|
|
|
|
'--build=%s' % self.ctx.build_triplet,
|
|
|
|
'--host=%s' % self.triplet,
|
|
|
|
'--prefix=',
|
|
|
|
'--disable-profile', '--without-parted',
|
|
|
|
'CC=%s-gcc -nostdlib' % self.triplet])
|
|
|
|
cmdlist.add_command('install', ['make', 'prefix=%s' % self.sysroot,
|
|
|
|
'no_deps=t', 'install-headers'])
|
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
cmdlist.pop_subdesc()
|
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
def build_gcc(self, cmdlist, bootstrap):
|
|
|
|
"""Build GCC."""
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
# libssp is of little relevance with glibc's own stack
|
|
|
|
# checking support. libcilkrts does not support GNU/Hurd (and
|
|
|
|
# has been removed in GCC 8, so --disable-libcilkrts can be
|
|
|
|
# removed once glibc no longer supports building with older
|
2021-11-08 15:49:11 +00:00
|
|
|
# GCC versions). --enable-initfini-array is enabled by default
|
|
|
|
# in GCC 12, which can be removed when GCC 12 becomes the
|
|
|
|
# minimum requirement.
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
cfg_opts = list(self.gcc_cfg)
|
2021-06-09 12:29:16 +00:00
|
|
|
cfg_opts += ['--enable-initfini-array']
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
cfg_opts += ['--disable-libssp', '--disable-libcilkrts']
|
2016-11-17 17:45:41 +00:00
|
|
|
host_libs = self.ctx.host_libraries_installdir
|
|
|
|
cfg_opts += ['--with-gmp=%s' % host_libs,
|
|
|
|
'--with-mpfr=%s' % host_libs,
|
|
|
|
'--with-mpc=%s' % host_libs]
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
if bootstrap:
|
|
|
|
tool_build = 'gcc-first'
|
|
|
|
# Building a static-only, C-only compiler that is
|
|
|
|
# sufficient to build glibc. Various libraries and
|
|
|
|
# features that may require libc headers must be disabled.
|
|
|
|
# When configuring with a sysroot, --with-newlib is
|
|
|
|
# required to define inhibit_libc (to stop some parts of
|
|
|
|
# libgcc including libc headers); --without-headers is not
|
|
|
|
# sufficient.
|
|
|
|
cfg_opts += ['--enable-languages=c', '--disable-shared',
|
|
|
|
'--disable-threads',
|
|
|
|
'--disable-libatomic',
|
|
|
|
'--disable-decimal-float',
|
2023-04-01 19:09:19 +00:00
|
|
|
'--disable-gcov',
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'--disable-libffi',
|
|
|
|
'--disable-libgomp',
|
|
|
|
'--disable-libitm',
|
|
|
|
'--disable-libmpx',
|
|
|
|
'--disable-libquadmath',
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
'--disable-libsanitizer',
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
'--without-headers', '--with-newlib',
|
|
|
|
'--with-glibc-version=%s' % self.ctx.glibc_version
|
|
|
|
]
|
|
|
|
cfg_opts += self.first_gcc_cfg
|
|
|
|
else:
|
|
|
|
tool_build = 'gcc'
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
# libsanitizer commonly breaks because of glibc header
|
2019-12-17 15:23:08 +00:00
|
|
|
# changes, or on unusual targets. C++ pre-compiled
|
|
|
|
# headers are not used during the glibc build and are
|
|
|
|
# expensive to create.
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
if not self.ctx.full_gcc:
|
2019-12-17 15:23:08 +00:00
|
|
|
cfg_opts += ['--disable-libsanitizer',
|
|
|
|
'--disable-libstdcxx-pch']
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
langs = 'all' if self.ctx.full_gcc else 'c,c++'
|
|
|
|
cfg_opts += ['--enable-languages=%s' % langs,
|
|
|
|
'--enable-shared', '--enable-threads']
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.build_cross_tool(cmdlist, 'gcc', tool_build, cfg_opts)
|
|
|
|
|
2020-01-02 09:18:31 +00:00
|
|
|
class GlibcPolicyDefault(object):
|
|
|
|
"""Build policy for glibc: common defaults."""
|
|
|
|
|
|
|
|
def __init__(self, glibc):
|
|
|
|
self.srcdir = glibc.ctx.component_srcdir('glibc')
|
|
|
|
self.use_usr = glibc.os != 'gnu'
|
|
|
|
self.prefix = '/usr' if self.use_usr else ''
|
|
|
|
self.configure_args = [
|
|
|
|
'--prefix=%s' % self.prefix,
|
|
|
|
'--enable-profile',
|
|
|
|
'--build=%s' % glibc.ctx.build_triplet,
|
|
|
|
'--host=%s' % glibc.triplet,
|
|
|
|
'CC=%s' % glibc.tool_name('gcc'),
|
|
|
|
'CXX=%s' % glibc.tool_name('g++'),
|
|
|
|
]
|
|
|
|
if glibc.os == 'gnu':
|
|
|
|
self.configure_args.append('MIG=%s' % glibc.tool_name('mig'))
|
2020-08-20 08:51:42 +00:00
|
|
|
if glibc.cflags:
|
|
|
|
self.configure_args.append('CFLAGS=%s' % glibc.cflags)
|
|
|
|
self.configure_args.append('CXXFLAGS=%s' % glibc.cflags)
|
2020-01-02 09:18:31 +00:00
|
|
|
self.configure_args += glibc.cfg
|
|
|
|
|
|
|
|
def configure(self, cmdlist):
|
|
|
|
"""Invoked to add the configure command to the command list."""
|
|
|
|
cmdlist.add_command('configure',
|
|
|
|
[os.path.join(self.srcdir, 'configure'),
|
|
|
|
*self.configure_args])
|
|
|
|
|
|
|
|
def extra_commands(self, cmdlist):
|
|
|
|
"""Invoked to inject additional commands (make check) after build."""
|
|
|
|
pass
|
|
|
|
|
|
|
|
class GlibcPolicyForCompiler(GlibcPolicyDefault):
|
|
|
|
"""Build policy for glibc during the compilers stage."""
|
|
|
|
|
|
|
|
def __init__(self, glibc):
|
|
|
|
super().__init__(glibc)
|
|
|
|
self.builddir = glibc.ctx.component_builddir(
|
|
|
|
'compilers', glibc.compiler.name, 'glibc', glibc.name)
|
|
|
|
self.installdir = glibc.compiler.sysroot
|
|
|
|
|
|
|
|
class GlibcPolicyForBuild(GlibcPolicyDefault):
|
|
|
|
"""Build policy for glibc during the glibcs stage."""
|
|
|
|
|
|
|
|
def __init__(self, glibc):
|
|
|
|
super().__init__(glibc)
|
|
|
|
self.builddir = glibc.ctx.component_builddir(
|
|
|
|
'glibcs', glibc.name, 'glibc')
|
|
|
|
self.installdir = glibc.ctx.glibc_installdir(glibc.name)
|
|
|
|
if glibc.ctx.strip:
|
|
|
|
self.strip = glibc.tool_name('strip')
|
|
|
|
else:
|
|
|
|
self.strip = None
|
|
|
|
self.save_logs = glibc.ctx.save_logs
|
|
|
|
|
|
|
|
def extra_commands(self, cmdlist):
|
|
|
|
if self.strip:
|
2021-09-16 14:08:05 +00:00
|
|
|
# Avoid stripping libc.so and libpthread.so, which are
|
|
|
|
# linker scripts stored in /lib on Hurd.
|
|
|
|
find_command = 'find %s/lib* -name "*.so*"' % self.installdir
|
|
|
|
cmdlist.add_command('strip', ['sh', '-c', (
|
|
|
|
'set -e; for f in $(%s); do '
|
|
|
|
'if ! head -c16 $f | grep -q "GNU ld script"; then %s $f; fi; '
|
|
|
|
'done' % (find_command, self.strip))])
|
2020-01-02 09:18:31 +00:00
|
|
|
cmdlist.add_command('check', ['make', 'check'])
|
|
|
|
cmdlist.add_command('save-logs', [self.save_logs], always_run=True)
|
|
|
|
|
2020-01-02 09:18:34 +00:00
|
|
|
class GlibcPolicyForUpdateSyscalls(GlibcPolicyDefault):
|
|
|
|
"""Build policy for glibc during update-syscalls."""
|
|
|
|
|
|
|
|
def __init__(self, glibc):
|
|
|
|
super().__init__(glibc)
|
|
|
|
self.builddir = glibc.ctx.component_builddir(
|
|
|
|
'update-syscalls', glibc.name, 'glibc')
|
|
|
|
self.linuxdir = glibc.ctx.component_builddir(
|
|
|
|
'update-syscalls', glibc.name, 'linux')
|
|
|
|
self.linux_policy = LinuxHeadersPolicyForUpdateSyscalls(
|
|
|
|
glibc, self.linuxdir)
|
|
|
|
self.configure_args.insert(
|
|
|
|
0, '--with-headers=%s' % os.path.join(self.linuxdir, 'include'))
|
|
|
|
# self.installdir not set because installation is not supported
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
2016-11-14 23:48:50 +00:00
|
|
|
class Glibc(object):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""A configuration for building glibc."""
|
|
|
|
|
|
|
|
def __init__(self, compiler, arch=None, os_name=None, variant=None,
|
2020-08-20 08:51:42 +00:00
|
|
|
cfg=None, ccopts=None, cflags=None):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""Initialize a Glibc object."""
|
|
|
|
self.ctx = compiler.ctx
|
|
|
|
self.compiler = compiler
|
|
|
|
if arch is None:
|
|
|
|
self.arch = compiler.arch
|
|
|
|
else:
|
|
|
|
self.arch = arch
|
|
|
|
if os_name is None:
|
|
|
|
self.os = compiler.os
|
|
|
|
else:
|
|
|
|
self.os = os_name
|
|
|
|
self.variant = variant
|
|
|
|
if variant is None:
|
|
|
|
self.name = '%s-%s' % (self.arch, self.os)
|
|
|
|
else:
|
|
|
|
self.name = '%s-%s-%s' % (self.arch, self.os, variant)
|
|
|
|
self.triplet = '%s-glibc-%s' % (self.arch, self.os)
|
|
|
|
if cfg is None:
|
|
|
|
self.cfg = []
|
|
|
|
else:
|
|
|
|
self.cfg = cfg
|
2020-08-20 08:51:42 +00:00
|
|
|
# ccopts contain ABI options and are passed to configure as CC / CXX.
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.ccopts = ccopts
|
2020-08-20 08:51:42 +00:00
|
|
|
# cflags contain non-ABI options like -g or -O and are passed to
|
|
|
|
# configure as CFLAGS / CXXFLAGS.
|
|
|
|
self.cflags = cflags
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def tool_name(self, tool):
|
|
|
|
"""Return the name of a cross-compilation tool."""
|
|
|
|
ctool = '%s-%s' % (self.compiler.triplet, tool)
|
|
|
|
if self.ccopts and (tool == 'gcc' or tool == 'g++'):
|
|
|
|
ctool = '%s %s' % (ctool, self.ccopts)
|
|
|
|
return ctool
|
|
|
|
|
|
|
|
def build(self):
|
|
|
|
"""Generate commands to build this glibc."""
|
|
|
|
builddir = self.ctx.component_builddir('glibcs', self.name, 'glibc')
|
|
|
|
installdir = self.ctx.glibc_installdir(self.name)
|
|
|
|
logsdir = os.path.join(self.ctx.logsdir, 'glibcs', self.name)
|
|
|
|
self.ctx.remove_recreate_dirs(installdir, builddir, logsdir)
|
|
|
|
cmdlist = CommandList('glibcs-%s' % self.name, self.ctx.keep)
|
|
|
|
cmdlist.add_command('check-compilers',
|
|
|
|
['test', '-f',
|
|
|
|
os.path.join(self.compiler.installdir, 'ok')])
|
|
|
|
cmdlist.use_path(self.compiler.bindir)
|
2020-01-02 09:18:31 +00:00
|
|
|
self.build_glibc(cmdlist, GlibcPolicyForBuild(self))
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
self.ctx.add_makefile_cmdlist('glibcs-%s' % self.name, cmdlist,
|
|
|
|
logsdir)
|
|
|
|
|
2020-01-02 09:18:31 +00:00
|
|
|
def build_glibc(self, cmdlist, policy):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""Generate commands to build this glibc, either as part of a compiler
|
|
|
|
build or with the bootstrapped compiler (and in the latter case, run
|
|
|
|
tests as well)."""
|
2020-01-02 09:18:31 +00:00
|
|
|
cmdlist.create_use_dir(policy.builddir)
|
|
|
|
policy.configure(cmdlist)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
cmdlist.add_command('build', ['make'])
|
|
|
|
cmdlist.add_command('install', ['make', 'install',
|
2020-01-02 09:18:31 +00:00
|
|
|
'install_root=%s' % policy.installdir])
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
# GCC uses paths such as lib/../lib64, so make sure lib
|
|
|
|
# directories always exist.
|
2018-01-24 01:18:54 +00:00
|
|
|
mkdir_cmd = ['mkdir', '-p',
|
2020-01-02 09:18:31 +00:00
|
|
|
os.path.join(policy.installdir, 'lib')]
|
|
|
|
if policy.use_usr:
|
|
|
|
mkdir_cmd += [os.path.join(policy.installdir, 'usr', 'lib')]
|
2018-01-24 01:18:54 +00:00
|
|
|
cmdlist.add_command('mkdir-lib', mkdir_cmd)
|
2020-01-02 09:18:31 +00:00
|
|
|
policy.extra_commands(cmdlist)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
|
2020-01-02 09:18:34 +00:00
|
|
|
def update_syscalls(self):
|
|
|
|
if self.os == 'gnu':
|
|
|
|
# Hurd does not have system call tables that need updating.
|
|
|
|
return
|
|
|
|
|
|
|
|
policy = GlibcPolicyForUpdateSyscalls(self)
|
|
|
|
logsdir = os.path.join(self.ctx.logsdir, 'update-syscalls', self.name)
|
|
|
|
self.ctx.remove_recreate_dirs(policy.builddir, logsdir)
|
|
|
|
cmdlist = CommandList('update-syscalls-%s' % self.name, self.ctx.keep)
|
|
|
|
cmdlist.add_command('check-compilers',
|
|
|
|
['test', '-f',
|
|
|
|
os.path.join(self.compiler.installdir, 'ok')])
|
|
|
|
cmdlist.use_path(self.compiler.bindir)
|
|
|
|
|
|
|
|
install_linux_headers(policy.linux_policy, cmdlist)
|
|
|
|
|
|
|
|
cmdlist.create_use_dir(policy.builddir)
|
|
|
|
policy.configure(cmdlist)
|
|
|
|
cmdlist.add_command('build', ['make', 'update-syscall-lists'])
|
|
|
|
cmdlist.cleanup_dir()
|
|
|
|
self.ctx.add_makefile_cmdlist('update-syscalls-%s' % self.name,
|
|
|
|
cmdlist, logsdir)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
2016-11-14 23:48:50 +00:00
|
|
|
class Command(object):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""A command run in the build process."""
|
|
|
|
|
|
|
|
def __init__(self, desc, num, dir, path, command, always_run=False):
|
|
|
|
"""Initialize a Command object."""
|
|
|
|
self.dir = dir
|
|
|
|
self.path = path
|
|
|
|
self.desc = desc
|
|
|
|
trans = str.maketrans({' ': '-'})
|
|
|
|
self.logbase = '%03d-%s' % (num, desc.translate(trans))
|
|
|
|
self.command = command
|
|
|
|
self.always_run = always_run
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def shell_make_quote_string(s):
|
|
|
|
"""Given a string not containing a newline, quote it for use by the
|
|
|
|
shell and make."""
|
|
|
|
assert '\n' not in s
|
|
|
|
if re.fullmatch('[]+,./0-9@A-Z_a-z-]+', s):
|
|
|
|
return s
|
|
|
|
strans = str.maketrans({"'": "'\\''"})
|
|
|
|
s = "'%s'" % s.translate(strans)
|
|
|
|
mtrans = str.maketrans({'$': '$$'})
|
|
|
|
return s.translate(mtrans)
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
def shell_make_quote_list(l, translate_make):
|
|
|
|
"""Given a list of strings not containing newlines, quote them for use
|
|
|
|
by the shell and make, returning a single string. If translate_make
|
|
|
|
is true and the first string is 'make', change it to $(MAKE)."""
|
|
|
|
l = [Command.shell_make_quote_string(s) for s in l]
|
|
|
|
if translate_make and l[0] == 'make':
|
|
|
|
l[0] = '$(MAKE)'
|
|
|
|
return ' '.join(l)
|
|
|
|
|
|
|
|
def shell_make_quote(self):
|
|
|
|
"""Return this command quoted for the shell and make."""
|
|
|
|
return self.shell_make_quote_list(self.command, True)
|
|
|
|
|
|
|
|
|
2016-11-14 23:48:50 +00:00
|
|
|
class CommandList(object):
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
"""A list of commands run in the build process."""
|
|
|
|
|
|
|
|
def __init__(self, desc, keep):
|
|
|
|
"""Initialize a CommandList object."""
|
|
|
|
self.cmdlist = []
|
|
|
|
self.dir = None
|
|
|
|
self.path = None
|
|
|
|
self.desc = [desc]
|
|
|
|
self.keep = keep
|
|
|
|
|
|
|
|
def desc_txt(self, desc):
|
|
|
|
"""Return the description to use for a command."""
|
|
|
|
return '%s %s' % (' '.join(self.desc), desc)
|
|
|
|
|
|
|
|
def use_dir(self, dir):
|
|
|
|
"""Set the default directory for subsequent commands."""
|
|
|
|
self.dir = dir
|
|
|
|
|
|
|
|
def use_path(self, path):
|
|
|
|
"""Set a directory to be prepended to the PATH for subsequent
|
|
|
|
commands."""
|
|
|
|
self.path = path
|
|
|
|
|
|
|
|
def push_subdesc(self, subdesc):
|
|
|
|
"""Set the default subdescription for subsequent commands (e.g., the
|
|
|
|
name of a component being built, within the series of commands
|
|
|
|
building it)."""
|
|
|
|
self.desc.append(subdesc)
|
|
|
|
|
|
|
|
def pop_subdesc(self):
|
|
|
|
"""Pop a subdescription from the list of descriptions."""
|
|
|
|
self.desc.pop()
|
|
|
|
|
|
|
|
def create_use_dir(self, dir):
|
|
|
|
"""Remove and recreate a directory and use it for subsequent
|
|
|
|
commands."""
|
|
|
|
self.add_command_dir('rm', None, ['rm', '-rf', dir])
|
|
|
|
self.add_command_dir('mkdir', None, ['mkdir', '-p', dir])
|
|
|
|
self.use_dir(dir)
|
|
|
|
|
|
|
|
def add_command_dir(self, desc, dir, command, always_run=False):
|
|
|
|
"""Add a command to run in a given directory."""
|
|
|
|
cmd = Command(self.desc_txt(desc), len(self.cmdlist), dir, self.path,
|
|
|
|
command, always_run)
|
|
|
|
self.cmdlist.append(cmd)
|
|
|
|
|
|
|
|
def add_command(self, desc, command, always_run=False):
|
|
|
|
"""Add a command to run in the default directory."""
|
|
|
|
cmd = Command(self.desc_txt(desc), len(self.cmdlist), self.dir,
|
|
|
|
self.path, command, always_run)
|
|
|
|
self.cmdlist.append(cmd)
|
|
|
|
|
|
|
|
def cleanup_dir(self, desc='cleanup', dir=None):
|
|
|
|
"""Clean up a build directory. If no directory is specified, the
|
|
|
|
default directory is cleaned up and ceases to be the default
|
|
|
|
directory."""
|
|
|
|
if dir is None:
|
|
|
|
dir = self.dir
|
|
|
|
self.use_dir(None)
|
|
|
|
if self.keep != 'all':
|
|
|
|
self.add_command_dir(desc, None, ['rm', '-rf', dir],
|
|
|
|
always_run=(self.keep == 'none'))
|
|
|
|
|
|
|
|
def makefile_commands(self, wrapper, logsdir):
|
|
|
|
"""Return the sequence of commands in the form of text for a Makefile.
|
|
|
|
The given wrapper script takes arguments: base of logs for
|
|
|
|
previous command, or empty; base of logs for this command;
|
|
|
|
description; directory; PATH addition; the command itself."""
|
|
|
|
# prev_base is the base of the name for logs of the previous
|
|
|
|
# command that is not always-run (that is, a build command,
|
|
|
|
# whose failure should stop subsequent build commands from
|
|
|
|
# being run, as opposed to a cleanup command, which is run
|
|
|
|
# even if previous commands failed).
|
|
|
|
prev_base = ''
|
|
|
|
cmds = []
|
|
|
|
for c in self.cmdlist:
|
|
|
|
ctxt = c.shell_make_quote()
|
|
|
|
if prev_base and not c.always_run:
|
|
|
|
prev_log = os.path.join(logsdir, prev_base)
|
|
|
|
else:
|
|
|
|
prev_log = ''
|
|
|
|
this_log = os.path.join(logsdir, c.logbase)
|
|
|
|
if not c.always_run:
|
|
|
|
prev_base = c.logbase
|
|
|
|
if c.dir is None:
|
|
|
|
dir = ''
|
|
|
|
else:
|
|
|
|
dir = c.dir
|
|
|
|
if c.path is None:
|
|
|
|
path = ''
|
|
|
|
else:
|
|
|
|
path = c.path
|
|
|
|
prelims = [wrapper, prev_log, this_log, c.desc, dir, path]
|
|
|
|
prelim_txt = Command.shell_make_quote_list(prelims, False)
|
|
|
|
cmds.append('\t@%s %s' % (prelim_txt, ctxt))
|
|
|
|
return '\n'.join(cmds)
|
|
|
|
|
2016-11-26 00:10:24 +00:00
|
|
|
def status_logs(self, logsdir):
|
|
|
|
"""Return the list of log files with command status."""
|
|
|
|
return [os.path.join(logsdir, '%s-status.txt' % c.logbase)
|
|
|
|
for c in self.cmdlist]
|
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
|
|
|
|
def get_parser():
|
|
|
|
"""Return an argument parser for this module."""
|
|
|
|
parser = argparse.ArgumentParser(description=__doc__)
|
|
|
|
parser.add_argument('-j', dest='parallelism',
|
|
|
|
help='Run this number of jobs in parallel',
|
|
|
|
type=int, default=os.cpu_count())
|
|
|
|
parser.add_argument('--keep', dest='keep',
|
|
|
|
help='Whether to keep all build directories, '
|
|
|
|
'none or only those from failed builds',
|
|
|
|
default='none', choices=('none', 'all', 'failed'))
|
2016-11-24 22:25:58 +00:00
|
|
|
parser.add_argument('--replace-sources', action='store_true',
|
|
|
|
help='Remove and replace source directories '
|
|
|
|
'with the wrong version of a component')
|
2016-12-07 21:29:24 +00:00
|
|
|
parser.add_argument('--strip', action='store_true',
|
|
|
|
help='Strip installed glibc libraries')
|
Add build-many-glibcs.py support for building more GCC libraries.
Every so often we get libsanitizer or libgo builds breaking with new
glibc because of some change in the glibc headers.
glibc's build-many-glibcs.py deliberately disables libsanitizer and
GCC languages other than C and C++ because the point is to test glibc
and find glibc problems (including problems shown up by new compiler
warnings in new GCC), not to test libsanitizer or libgo; if the
compiler build fails because of libsanitizer or libgo failing to
build, that could hide the existence of new problems in glibc.
However, it seems reasonable to have a non-default mode where
build-many-glibcs.py does build those additional pieces, which this
patch adds.
Note that I do not intend to run a build-many-glibcs.py bot with this
new option. If people concerned with libsanitizer, libgo or other
potentially affected GCC libraries wish to find out about such
problems more quickly, they may wish to run such a bot or bots (and to
monitor the results and fix issues found - obviously there will be
some overlap with issues found by my bots not using that option).
Note also that building a non-native Ada compiler requires a
sufficiently recent native (or build-x-host, in general) Ada compiler
to be used, possibly more or less the same version as being built.
That needs to be in the PATH when build-many-glibcs.py --full-gcc is
run; the script does not deal with setting up such a compiler (or any
of the other host tools needed for building GCC and glibc, beyond the
GMP / MPFR / MPC libraries), but perhaps it should, to avoid the need
to keep updating such a compiler manually when running a bot.
Tested by running build-many-glibcs.py with the new option, with
mainline GCC. There are build failures for various configurations,
which may be of interest to Go / Ada people even if you're not
interested in running such a bot:
* mips64 / mips64el (all configuration): ICE building libstdc++, as
seen without using the new option
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156>.
* aarch64_be: error building libgo (little-endian aarch64 works fine):
version.go:67:13: error: expected ';' or ')' or newline
67 | BigEndian =
| ^
version.go:67:3: error: reference to undefined name 'BigEndian'
67 | BigEndian =
| ^
* arm (all configurations): error building libgo:
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:29:5: error: reference to undefined name 'randomTrap'
29 | if randomTrap == 0 {
| ^
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/internal/syscall/unix/getrandom_linux.go:38:34: error: reference to undefined name 'randomTrap'
38 | r1, _, errno := syscall.Syscall(randomTrap,
| ^
What's happening there is, I think, that the arm*b*-*-* case in
libgo/configure.ac is wrongly matching arm-glibc-linux-gnueabi with
the 'b' in the vendor part, and then something else is failing to
handle GOARCH=armbe. Given that you can have configurations with
multilibs of both endiannesses, endianness should always be detected
by configure.ac, for all architectures, using a compile test of
whether __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, not based on textual
matches to the host (= target at top-level) triplet.
* armeb (all configurations): error building libada (for some reason
the Arm libada configuration seems to do different things for EH for
big-endian, which makes no sense to me and doesn't actually work):
a-exexpr.adb:87:06: "System.Exceptions.Machine" is not a predefined library unit
a-exexpr.adb:87:06: "Ada.Exceptions (body)" depends on "Ada.Exceptions.Exception_Propagation (body)"
a-exexpr.adb:87:06: "Ada.Exceptions.Exception_Propagation (body)" depends on "System.Exceptions.Machine (spec)"
* hppa: error building libgo (same error as for aarch64_be).
* ia64: ICE building libgo. I've filed
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281> for this.
* m68k: ICE in the Go front end building libgo
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948>.
* microblaze, microblazeel, nios2, sh3, sh3eb: build failure in libada
for lack of a libada port to those systems (I'm not sure sh3 would
actually need anything different from sh4):
a-cbdlli.ads:38:14: violation of restriction "No_Finalization" at system.ads:47
* i686-gnu: build failure in libada, might be fixed by the patch
attached to <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81103>
(not tested):
terminals.c:1115:13: fatal error: termio.h: No such file or directory
* scripts/build-many-glibcs.py (Context.__init__): Add full_gcc
argument.
(Config.build_gcc): Use --disable-libsanitizer for first GCC
build, but not for second build if --full-gcc. Use
--enable-languages=all for second build if --full-gcc.
(get_parser): Add --full-gcc option.
(main): Update call to Context.
2018-09-11 12:02:28 +00:00
|
|
|
parser.add_argument('--full-gcc', action='store_true',
|
|
|
|
help='Build GCC with all languages and libsanitizer')
|
2020-02-28 11:32:28 +00:00
|
|
|
parser.add_argument('--shallow', action='store_true',
|
|
|
|
help='Do not download Git history during checkout')
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
parser.add_argument('topdir',
|
|
|
|
help='Toplevel working directory')
|
|
|
|
parser.add_argument('action',
|
|
|
|
help='What to do',
|
2016-12-01 00:09:25 +00:00
|
|
|
choices=('checkout', 'bot-cycle', 'bot',
|
2020-01-02 09:18:34 +00:00
|
|
|
'host-libraries', 'compilers', 'glibcs',
|
2020-02-29 11:44:31 +00:00
|
|
|
'update-syscalls', 'list-compilers',
|
|
|
|
'list-glibcs'))
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
parser.add_argument('configs',
|
|
|
|
help='Versions to check out or configurations to build',
|
|
|
|
nargs='*')
|
|
|
|
return parser
|
|
|
|
|
|
|
|
|
2024-01-31 23:46:23 +00:00
|
|
|
def get_version_common(progname,line,word,arg1):
|
2023-09-21 21:24:05 +00:00
|
|
|
try:
|
|
|
|
out = subprocess.run([progname, arg1],
|
|
|
|
stdout=subprocess.PIPE,
|
|
|
|
stderr=subprocess.DEVNULL,
|
|
|
|
stdin=subprocess.DEVNULL,
|
|
|
|
check=True, universal_newlines=True)
|
|
|
|
v = out.stdout.splitlines()[line].split()[word]
|
2024-01-31 23:46:23 +00:00
|
|
|
v = re.match(r'[0-9]+(.[0-9]+)*', v).group()
|
2023-09-21 21:24:05 +00:00
|
|
|
return [int(x) for x in v.split('.')]
|
|
|
|
except:
|
|
|
|
return 'missing';
|
|
|
|
|
2024-01-31 23:46:23 +00:00
|
|
|
def get_version_common_stderr(progname,line,word,arg1):
|
2023-09-21 21:24:05 +00:00
|
|
|
try:
|
|
|
|
out = subprocess.run([progname, arg1],
|
|
|
|
stdout=subprocess.DEVNULL,
|
|
|
|
stderr=subprocess.PIPE,
|
|
|
|
stdin=subprocess.DEVNULL,
|
|
|
|
check=True, universal_newlines=True)
|
|
|
|
v = out.stderr.splitlines()[line].split()[word]
|
2024-01-31 23:46:23 +00:00
|
|
|
v = re.match(r'[0-9]+(.[0-9]+)*', v).group()
|
2023-09-21 21:24:05 +00:00
|
|
|
return [int(x) for x in v.split('.')]
|
|
|
|
except:
|
|
|
|
return 'missing';
|
|
|
|
|
|
|
|
def get_version(progname):
|
2024-01-31 23:46:23 +00:00
|
|
|
return get_version_common(progname, 0, -1, '--version');
|
2023-09-21 21:24:05 +00:00
|
|
|
|
|
|
|
def get_version_awk(progname):
|
2024-01-31 23:46:23 +00:00
|
|
|
return get_version_common(progname, 0, 2, '--version');
|
2023-09-21 21:24:05 +00:00
|
|
|
|
|
|
|
def get_version_bzip2(progname):
|
2024-01-31 23:46:23 +00:00
|
|
|
return get_version_common_stderr(progname, 0, 6, '-h');
|
2023-09-21 21:24:05 +00:00
|
|
|
|
|
|
|
def check_version(ver, req):
|
|
|
|
for v, r in zip(ver, req):
|
|
|
|
if v > r:
|
|
|
|
return True
|
|
|
|
if v < r:
|
|
|
|
return False
|
|
|
|
return True
|
|
|
|
|
|
|
|
def version_str(ver):
|
|
|
|
return '.'.join([str (x) for x in ver])
|
|
|
|
|
|
|
|
def check_for_required_tools():
|
|
|
|
get_list_of_required_tools()
|
|
|
|
count_old_tools = 0
|
|
|
|
count_missing_tools = 0
|
2023-10-30 16:03:28 +00:00
|
|
|
|
2023-09-21 21:24:05 +00:00
|
|
|
for k, v in REQUIRED_TOOLS.items():
|
|
|
|
version = v[0](k)
|
|
|
|
if version == 'missing':
|
|
|
|
ok = 'missing'
|
|
|
|
else:
|
|
|
|
ok = 'ok' if check_version (version, v[1]) else 'old'
|
|
|
|
if ok == 'old':
|
|
|
|
if count_old_tools == 0:
|
|
|
|
print("One or more required tools are too old:")
|
|
|
|
count_old_tools = count_old_tools + 1
|
|
|
|
print('{:9}: {:3} (obtained=\"{}\" required=\"{}\")'.format(k, ok,
|
|
|
|
version_str(version), version_str(v[1])))
|
|
|
|
if ok == 'missing':
|
|
|
|
if count_missing_tools == 0:
|
|
|
|
print("One or more required tools are missing:")
|
|
|
|
count_missing_tools = count_missing_tools + 1
|
|
|
|
print('{:9}: {:3} (required=\"{}\")'.format(k, ok,
|
|
|
|
version_str(v[1])))
|
2023-10-30 16:03:28 +00:00
|
|
|
|
2023-09-21 21:24:05 +00:00
|
|
|
if count_old_tools > 0 or count_missing_tools > 0:
|
|
|
|
exit (1);
|
2023-10-30 16:03:28 +00:00
|
|
|
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
def main(argv):
|
|
|
|
"""The main entry point."""
|
2023-09-21 21:24:05 +00:00
|
|
|
check_for_required_tools();
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
parser = get_parser()
|
|
|
|
opts = parser.parse_args(argv)
|
|
|
|
topdir = os.path.abspath(opts.topdir)
|
2016-11-24 22:25:58 +00:00
|
|
|
ctx = Context(topdir, opts.parallelism, opts.keep, opts.replace_sources,
|
2020-02-28 11:32:28 +00:00
|
|
|
opts.strip, opts.full_gcc, opts.action,
|
|
|
|
shallow=opts.shallow)
|
Add script to build many glibc configurations.
This patch adds a Python (3.5 or later) script to build many different
configurations of glibc, including building the required cross
compilers first. It's not intended to change any patch testing
requirements, although some people may wish to use it for high-risk
patches such as adding warning options (and it can also be used to
test building, including compiling tests, for an individual
configuration, if e.g. you wish to do such a compilation test of a
patch for an architecture it touches).
The configurations include all the GNU/Linux ABI variants in
<https://sourceware.org/glibc/wiki/ABIList> (although some do not yet
build cleanly) and it would be desirable to cover enough other
variants e.g. for CPUs using different sysdeps directories to test
building each piece of code in glibc at least once. It would also be
desirable to extend it to cover Hurd and NaCl, which might best be
done by people familiar with those configurations.
You call the script as
build-many-glibcs.py /some/where thing-to-do <other-arguments>
where /some/where is a working directory for the script. It will
create and use subdirectories build, install, logs therein. You can
use it with thing-to-do being "checkout" to create a subdirectory src
therein, with subdirectories binutils, gcc, glibc, gmp, linux, mpc,
mpfr with the sources of those components, or create those directories
manually (all except glibc can be symlinks to sources elsewhere). In
the checkout case, by default it checks out GCC 6 branch, binutils
2.27 branch, glibc mainline and releases of other components. You can
specify <component>-<version> to choose a version to check out, where
<version> is "vcs-mainline" or "vcs-<branch>" to check out from
version control (only supported for gcc, binutils, glibc) and
otherwise a release version number to download and use a tarball;
components not specified on the command line have default versions
checked out. If you rerun "checkout" (with the same version
specifications) it will update checkouts from version control, but
will not detect cases where the location something is expected to be
checked out from has changed.
Other than "checkout", thing-to-do is one of host-libraries,
compilers, glibcs. So you run, in that order:
build-many-glibcs.py /some/where host-libraries
build-many-glibcs.py /some/where compilers
build-many-glibcs.py /some/where glibcs
host-libraries is run once and then those libraries are used for all
the compilers. compilers can be run once and then used many times for
testing different glibc versions (so a bot only needs to update glibc
and rerun the glibcs task, if using stable GCC / binutils; if testing
the latest versions of the whole toolchain together including mainline
GCC, it would probably want to update everything and rerun both
compilers and glibcs). You can also name particular variants after
"compilers" or "glibcs" to build just those variants (the possible
variants are hardcoded in the script).
I may add support for allowing the set of configurations to depend on
the GCC version (to get cleaner default results), and optionally
looping over architecture-independent glibc variants of CFLAGS and
configure options as well, for every glibc configuration listed
(e.g. -Os).
GCC versions before 4.9 are not expected to work (the code uses
--with-glibc-version to get the bootstrap GCC appropriately
configured). There are various problems for particular configurations
as well.
Command-line options to the script: -jN to run N jobs in parallel
(default the number of CPU cores reported by the system); --keep=all
or --keep=failed to control keeping around build directories (default
--keep=none).
* scripts/build-many-glibcs.py: New file.
2016-11-11 21:07:08 +00:00
|
|
|
ctx.run_builds(opts.action, opts.configs)
|
|
|
|
|
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
main(sys.argv[1:])
|