[v3,01/19] Avoid race conditions when rebuilding librt.so

  `make check' sometimes triggers a rebuild of librt.so using
nptl/Makefile, which ignores librt's dependence on libpthread.  This
causes the build to blow up when we attempt to run the test suite on
RISC-V.
---
 nptl/Makefile | 4 ++++
 1 file changed, 4 insertions(+)
  

On Tue, 26 Dec 2017, Palmer Dabbelt wrote:

> `make check' sometimes triggers a rebuild of librt.so using
> nptl/Makefile, which ignores librt's dependence on libpthread.  This
> causes the build to blow up when we attempt to run the test suite on
> RISC-V.

OK, please commit, fixed as noted (with an appropriate ChangeLog entry, of 
course).

> +# `make check' sometimes triggers a rebuild of librt.so using this Makefile,

Should use neutral vertical quotes now in all new comments, 'make check', 
not `'.

> +# which ignores librt's dependence on libpthread

Need '.' at end of comment.
  

Who is racing with whom?  There should not be any parallelism involved
here.

Andreas.
  

On Mon, 01 Jan 2018 01:26:34 PST (-0800), schwab@linux-m68k.org wrote:
> Who is racing with whom?  There should not be any parallelism involved
> here.

I guess "race condition" isn't quite the right term: the non-determinism comes 
from the ordering by which make decides to re-build targets during a "make 
check" that occurs after a GCC "make install".  I ended up running into a 
handful of other problems along these lines, so instead it seems like the sane 
thing to do is to just "make && make check" in glibc instead.

I'll drop this patch.
  

On Sat, Jan 6, 2018 at 12:50 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> On Mon, 01 Jan 2018 01:26:34 PST (-0800), schwab@linux-m68k.org wrote:
>>
>> Who is racing with whom?  There should not be any parallelism involved
>> here.
>
>
> I guess "race condition" isn't quite the right term: the non-determinism
> comes from the ordering by which make decides to re-build targets during a
> "make check" that occurs after a GCC "make install".  I ended up running
> into a handful of other problems along these lines, so instead it seems like
> the sane thing to do is to just "make && make check" in glibc instead.
>
> I'll drop this patch.

I think you should install this patch.  Abstractly, "make check" is
supposed to work without further ceremony, regardless of whether "make
install" has just been run, and this particular missing dependency has
bitten me more than once myself.

zw