[ada,build] Avoid cp -p failures during Ada make install

Prompted by a known make install failure on Linux/x86_64, I decided to
finally rework my ancient patch

	http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01669.html

along the lines Mike suggested back then, i.e. use cp && touch -r
instead of cp -p.  This avoids the failures like

for file in rts/*.ad[sb]*; do \
    cp -p $file /vol/gcc/obj/gcc/gcc-10/vol/gcc/lib/gcc/x86_64-pc-linux-gnu/10.0.0/adainclude; \
done
cp: preserving permissions for ‘/vol/gcc/obj/gcc/gcc-10/vol/gcc/lib/gcc/x86_64-pc-linux-gnu/10.0.0/adainclude/a-assert.adb’: Operation not supported

when installing e.g. to an NFSv3 destination which doesn't support POSIX
ACLs from a local filesystem that does.

The fix turned out to be a bit more involved than I initially thought:

* I've changed INSTALL_DATA_DATE to use GNU make's $(call) function
  since the args are now needed twice.

* The destination argument now needs to include the filename: while cp
  can use a directory as destination, touch -r needs the full filename
  to preserve the timestamps.

* In order for $(notdir) to work which operates textually on its args,
  the loops had to be changed from shell for loops to make $(foreach)
  loops.

* And finally, to avoid exceeding the command line length limit, the
  individual commands have been separate by newlines, a trick learned
  from https://stackoverflow.com/questions/7039811/how-do-i-process-extremely-long-lists-of-files-in-a-make-recipe

When first testing this, the make install failed trying to install
standard.ads.h: while this gave just a warning with the old code

cp: cannot stat 'rts/standard.ads.h': No such file or directory

it now fails.  It turns out this is a dangling symlink

$ ls -l gcc/ada/rts/standard.ads.h
lrwxrwxrwx 1 ro gcc 50 May  7 18:13 gcc/ada/rts/standard.ads.h -> /vol/gcc/src/hg/trunk/local/gcc/ada/standard.ads.h
$ ls -lL gcc/ada/rts/standard.ads.h
ls: cannot access 'gcc/ada/rts/standard.ads.h': No such file or directory

introduced in r260921.  This is only present on mainline and the gcc-9
branch and the file seems never to have existed in tree, so I'm just
removing the reference.

Tested on x86_64-pc-linux-gnu installing both to a local filesystem and
an NFSv3 filesystem.

Ok for mainline (and the gcc-9 and gcc-8 branches eventually)?

Thanks.
	Rainer

> Tested on x86_64-pc-linux-gnu installing both to a local filesystem and
> an NFSv3 filesystem.
> 
> Ok for mainline (and the gcc-9 and gcc-8 branches eventually)?

No, this is not OK.

I'd rather keep the simple current logic and either stick to cp -p, or
use a proper $(INSTALL_whatever) as done elsewhere rather than adding more
kludges.

Also, standard.ads.h is a valid file, so the reference shouldn't be removed.

I'll add it to the repository, this was an oversight, thanks for noticing.

Arno

> Also, standard.ads.h is a valid file, so the reference shouldn't be removed.
> 
> I'll add it to the repository, this was an oversight, thanks for noticing.

I've added it now.

2019-05-08  Arnaud Charlet  <charlet@adacore.com>

	* standard.ads.h: New file.

Hi Arnaud,

>> Tested on x86_64-pc-linux-gnu installing both to a local filesystem and
>> an NFSv3 filesystem.
>> 
>> Ok for mainline (and the gcc-9 and gcc-8 branches eventually)?
>
> No, this is not OK.
>
> I'd rather keep the simple current logic and either stick to cp -p, or
> use a proper $(INSTALL_whatever) as done elsewhere rather than adding more
> kludges.

how do you mean, `proper $(INSTALL_whatever)'?

I've run the cp -p under strace, which shows

fgetxattr(3, "system.posix_acl_access", 0x7fff96829fd0, 132) = -1 ENODATA (No data available)
fstat(3, {st_mode=S_IFREG|0644, st_size=35368, ...}) = 0
fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)

i.e. it tries to determine an extended attribute, is told there's none,
tries to set that none on the destination and chokes if that doesn't
work.  Seems pretty insane to me.

This is cp from coreutils 8.30 on Fedora 29, btw., not same ancient
prehistoric software.

	Rainer

> > No, this is not OK.
> >
> > I'd rather keep the simple current logic and either stick to cp -p, or
> > use a proper $(INSTALL_whatever) as done elsewhere rather than adding more
> > kludges.
> 
> how do you mean, `proper $(INSTALL_whatever)'?

Using e.g. INSTALL_DATA from configure.

> I've run the cp -p under strace, which shows
> 
> fgetxattr(3, "system.posix_acl_access", 0x7fff96829fd0, 132) = -1 ENODATA (No data available)
> fstat(3, {st_mode=S_IFREG|0644, st_size=35368, ...}) = 0
> fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
> 
> i.e. it tries to determine an extended attribute, is told there's none,
> tries to set that none on the destination and chokes if that doesn't
> work.  Seems pretty insane to me.
> 
> This is cp from coreutils 8.30 on Fedora 29, btw., not same ancient
> prehistoric software.

Did someone file a bug report there BTW?

Arno