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

When trying to install a freshly built gcc 4.9.0 on Solaris 9 and 10, I
ran into make install failures when using INSTALL_DATA_DATE:

cp: preserving permissions for '/vol/gcc-4.9/lib/gcc/i386-pc-solaris2.10/4.9.0/adalib/a-assert.ali': Operation not supported on transport endpoint

The problem is that the source filesystem is either UFS (supporting
POSIX ACLs) or ZFS (supporting NFSv4 ACLs), while the destination is an
NFS-mounted (NFSv3, which doesn't include support for NFSv4 ACLs) ZFS
filesystem (which cannot support UFS ACLs even if NFSv3 could), so cp -p
errors as above although the timestamps are preserved.

It seems to me that (as already done in one of three cases in the
install-gnatlib target) $(INSTALL_DATA_DATE) errors should be ignored,
to allow for such a case.

The following patch does just that and allowed the make install to
complete.

Ok for mainline?

	Rainer


2014-04-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* gcc-interface/Makefile.in (install-gnatlib): Ignore
	$(INSTALL_DATA_DATE) errors.

On Apr 25, 2014, at 6:41 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
> When trying to install a freshly built gcc 4.9.0 on Solaris 9 and 10, I
> ran into make install failures when using INSTALL_DATA_DATE:

Ick, I hate this patch.  You kill error checking for all, on something that is important, just because someone didn’t use a proper install script.  The proper install script would use enough options to tell it to copy all but not the things it cannot…  For example, if you actively strip acts from the source and then copy, it should not fail.  If it does, then it sounds like a bug in cp.

Mike Stump <mikestump@comcast.net> writes:

> On Apr 25, 2014, at 6:41 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>> When trying to install a freshly built gcc 4.9.0 on Solaris 9 and 10, I
>> ran into make install failures when using INSTALL_DATA_DATE:
>
> Ick, I hate this patch.  You kill error checking for all, on something
> that is important, just because someone didn’t use a proper install
> script.  The proper install script would use enough options to tell it
> to copy all but not the things it cannot… For example, if you actively
> strip acts from the source and then copy, it should not fail.  If it
> does, then it sounds like a bug in cp.

Agreed that this is ugly: ACL support in GNU coreutils has long been a
total mess; no idea if it has improved very recently.

OTOH, error handling for INSTALL_DATA_DATE is already inconsistent: one
instance ignores errors, two others don't, with no apparent reason for
the difference.

	Rainer

On Apr 25, 2014, at 10:01 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
> Agreed that this is ugly: ACL support in GNU coreutils has long been a
> total mess; no idea if it has improved very recently.

So, are there ACLs on these files?  If so, why?  If no ACLs, I fail to see how anything can error out no matter how poorly written it is.

What about cp a b && touch -r a b?  Seems safer, seem portable enough.

Mike Stump <mikestump@comcast.net> writes:

> On Apr 25, 2014, at 10:01 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>> Agreed that this is ugly: ACL support in GNU coreutils has long been a
>> total mess; no idea if it has improved very recently.
>
> So, are there ACLs on these files?  If so, why?  If no ACLs, I fail to see how anything can error out no matter how poorly written it is.

In the ZFS case, there's nothing but ACLs: Unix permissions are just
translated/mapped from them.  Copying ACLs between file systems with
different ACL systems (like POSIX vs. NFSv4) is approximate at best.

> What about cp a b && touch -r a b?  Seems safer, seem portable enough.

I don't see why this shouldn't work.  The Autoconf manual suggests there
are some problems (timestamp resolution) with touch -r, but cp -p is the
same, and no hint that touch -r might not be portable.

	Rainer

On Apr 25, 2014, at 10:12 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
>> What about cp a b && touch -r a b?  Seems safer, seem portable enough.
> 
> I don't see why this shouldn't work.

It won’t work on a machine from 1982…  Honest.  Life goes on, oh well…  cp a b && { touch -r a b || true; } is the portable version, if you want.  :-)

> It seems to me that (as already done in one of three cases in the
> install-gnatlib target) $(INSTALL_DATA_DATE) errors should be ignored,
> to allow for such a case.
> 
> The following patch does just that and allowed the make install to
> complete.
> 
> Ok for mainline?

No, it's not OK to ignore all such errors, and the permissions should
really be preserved, so such error really musn't be ignored.

Arno

Arnaud Charlet <charlet@adacore.com> writes:

>> It seems to me that (as already done in one of three cases in the
>> install-gnatlib target) $(INSTALL_DATA_DATE) errors should be ignored,
>> to allow for such a case.
>> 
>> The following patch does just that and allowed the make install to
>> complete.
>> 
>> Ok for mainline?
>
> No, it's not OK to ignore all such errors, and the permissions should
> really be preserved, so such error really musn't be ignored.

they are: this is a bug in (it seems) all recent version of coreutils
cp.  How about a version with cp and touch -r as Mike suggested instead?

	Rainer

Arnaud Charlet <charlet@adacore.com> writes:

>> It seems to me that (as already done in one of three cases in the
>> install-gnatlib target) $(INSTALL_DATA_DATE) errors should be ignored,
>> to allow for such a case.
>> 
>> The following patch does just that and allowed the make install to
>> complete.
>> 
>> Ok for mainline?
>
> No, it's not OK to ignore all such errors, and the permissions should
> really be preserved, so such error really musn't be ignored.

Alternatively, one could use tar to do the copy, like gcc/Makefile.in
(install-headers-tar).  It will preserve timestamps, too, and is likely
to be way faster than hundreds of individual invocations of cp -p.

	Rainer