Fix Hurd build with read-only source directory

  The logic for generating sysdeps/mach/hurd/bits/errno.h involves a
stamp file and $(move-if-change).

The temporary file (generated unconditionally) is generated in the
source directory.  This means that even if
sysdeps/mach/hurd/bits/errno.h is up to date, and has an up to date
timestamp, the build will fail if the source directory is read-only.
Even with a writable source directory, multiple concurrent builds for
i686-gnu with the same source directory could race to access the
temporary file (which always has the same name).

This patch uses the build directory for the temporary file instead to
avoid those problems.  (In the case where the file is out of date and
the temporary file does need to be moved to the source directory, if
there are multiple concurrent builds for i686-gnu with the same source
directory, and the source and build directories are on different
filesystems, it's possible there might still be races replacing the
file in the source directory, depending on exactly how mv handles such
cross-filesystem moves.  This is certainly no worse than the present
situation, where such a case would have races regardless of whether
the file is out of date or whether different filesystems are in use.)

Tested with a build-many-glibcs.py build for i686-gnu.

2018-11-27  Joseph Myers  <joseph@codesourcery.com>

	* sysdeps/mach/hurd/Makefile ($(common-objpfx)stamp-errnos): Use
	$(hurd-objpfx)bits/errno.h-tmp, not $(hurd)/bits/errno.h-tmp.
  

Joseph Myers, le mar. 27 nov. 2018 18:12:28 +0000, a ecrit:
> The logic for generating sysdeps/mach/hurd/bits/errno.h involves a
> stamp file and $(move-if-change).
> 
> The temporary file (generated unconditionally) is generated in the
> source directory.  This means that even if
> sysdeps/mach/hurd/bits/errno.h is up to date, and has an up to date
> timestamp, the build will fail if the source directory is read-only.
> Even with a writable source directory, multiple concurrent builds for
> i686-gnu with the same source directory could race to access the
> temporary file (which always has the same name).
> 
> This patch uses the build directory for the temporary file instead to
> avoid those problems.

Right :)

Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> (In the case where the file is out of date and
> the temporary file does need to be moved to the source directory, if
> there are multiple concurrent builds for i686-gnu with the same source
> directory, and the source and build directories are on different
> filesystems, it's possible there might still be races replacing the
> file in the source directory, depending on exactly how mv handles such
> cross-filesystem moves.  This is certainly no worse than the present
> situation, where such a case would have races regardless of whether
> the file is out of date or whether different filesystems are in use.)

Indeed. I guess we don't want to care about concurrent builds on
different systems?  A way to make it safer would be to move the file in
two steps: in scripts/move-if-change, after testing for difference, move
to "$2.$$", thus in the same directory but with a name which shouldn't
be getting conflicts, then move from "$2.$$" to "$2", which will have
filesystem-provided atomicity.

In practice, I wouldn't expect people to make parallel builds in a case
where the file needs to be updated.

Samuel
  

On Tue, 27 Nov 2018, Samuel Thibault wrote:

> Indeed. I guess we don't want to care about concurrent builds on
> different systems?  A way to make it safer would be to move the file in
> two steps: in scripts/move-if-change, after testing for difference, move
> to "$2.$$", thus in the same directory but with a name which shouldn't
> be getting conflicts, then move from "$2.$$" to "$2", which will have
> filesystem-provided atomicity.

Note that move-if-change comes from gnulib, so any such improvements would 
need to go there first.