This is the mail archive of the glibc-cvs@sourceware.org mailing list for the glibc project.


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

GNU C Library master sources branch master updated. glibc-2.24-647-gcd880aa


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  cd880aa2ccabecd1a258b39b987160f0e86fd52d (commit)
      from  0e8bac37d5e7823efbc2d1bb54c77e0603f44661 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=cd880aa2ccabecd1a258b39b987160f0e86fd52d

commit cd880aa2ccabecd1a258b39b987160f0e86fd52d
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Jan 18 23:13:09 2017 +0000

    Avoid parallel GCC install in build-many-glibcs.py.
    
    A recent build-many-glibcs.py build
    <https://sourceware.org/ml/libc-testresults/2017-q1/msg00067.html> ran
    into what proves to be an old known bug
    <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980> with parallel
    install of GCC (one which as discussed there might require automake
    changes to fix).  This patch makes build-many-glibcs.py avoid such
    intermittent failures from parallel install by using -j1 for GCC make
    install (the code in question also applies to binutils make install,
    but it doesn't seem worth trying to avoid -j1 there; the builds and
    installs of different toolchains are still fully parallel with each
    other, this is only about the case when there are few enough of those
    that multiple jobs can get used within a single make install).
    
    	* scripts/build-many-glibcs.py (Config.build_cross_tool): Use -j1
    	for make install.

diff --git a/ChangeLog b/ChangeLog
index c9a6d80..9961dc4 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2017-01-18  Joseph Myers  <joseph@codesourcery.com>
+
+	* scripts/build-many-glibcs.py (Config.build_cross_tool): Use -j1
+	for make install.
+
 2017-01-18  Siddhesh Poyarekar  <siddhesh@sourceware.org>
 
 	* po/bg.po: Merge from Translation Project.
diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index d27e70b..d2947e6 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -1173,7 +1173,17 @@ class Config(object):
             cfg_cmd.extend(extra_opts)
         cmdlist.add_command('configure', cfg_cmd)
         cmdlist.add_command('build', ['make'])
-        cmdlist.add_command('install', ['make', 'install'])
+        # 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'])
         cmdlist.cleanup_dir()
         cmdlist.pop_subdesc()
 

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                    |    5 +++++
 scripts/build-many-glibcs.py |   12 +++++++++++-
 2 files changed, 16 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
GNU C Library master sources


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