aboutsummaryrefslogtreecommitdiff
path: root/nss/bug-erange.c
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2017-01-18 23:13:09 +0000
committerJoseph Myers <joseph@codesourcery.com>2017-01-18 23:13:09 +0000
commitcd880aa2ccabecd1a258b39b987160f0e86fd52d (patch)
tree9fc6f2a4ef76b8f729a1f96d353e6e17b84e0e8e /nss/bug-erange.c
parent0e8bac37d5e7823efbc2d1bb54c77e0603f44661 (diff)
downloadglibc-cd880aa2ccabecd1a258b39b987160f0e86fd52d.tar
glibc-cd880aa2ccabecd1a258b39b987160f0e86fd52d.tar.gz
glibc-cd880aa2ccabecd1a258b39b987160f0e86fd52d.tar.bz2
glibc-cd880aa2ccabecd1a258b39b987160f0e86fd52d.zip
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.
Diffstat (limited to 'nss/bug-erange.c')
0 files changed, 0 insertions, 0 deletions