[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: avoid buggy AIX 5.3 cp -R.
From: |
Stefano Lattarini |
Subject: |
Re: avoid buggy AIX 5.3 cp -R. |
Date: |
Sat, 22 Jan 2011 14:09:27 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
[dropping autoconf-patches]
On Saturday 22 January 2011, Ralf Wildenhues wrote:
> automake/tests/fn99{,subdir}.test have been long-time failures on
> AIX 5.[123], but not 6.1 or newer (and IIRC not 4.3.3 either):
> http://autobuild.josefsson.org/automake/log-201101181921915482000.txt
>
> | + make distcheck
> | make dist-gzip am__post_remove_distdir='@:'
> | { test ! -d "fn99-1.0" || { find "fn99-1.0" -type d ! -perm -200
> -exec chmod u+w {} ';' && rm -fr "fn99-1.0"; }; }
> | test -d "fn99-1.0" || mkdir "fn99-1.0"
> | cp: 8???: A file or directory in the path name does not exist.
> | make: 1254-004 The error code from the last command is 1.
>
> I finally got myself to look at this a bit, and playing around with
> various directory depths and whether there are files in them, I can only
> come to the conclusion that this system's cp -R is simply unusable as it
> corrupts its memory depending on the source tree layout. I've even got
> it to dump core.
>
> Any reasons against these two patches, for Autoconf master and Automake
> maint?
>
> It might be possible to rework the distdir rule to use maybe
> tar cBf - files | (cd $(distdir) && tar xf -)
>
> but that opens up its own set of problems (are ACLs copied? is the
> sub-second time stamp handling the same as that of cp?) I'm not eager
> to pursue this unless we see a real-life bug report from somebody who
> needs it to work on AIX.
>
FWIW, I agree it's better to go with the workaround in the testsuite,
especially because, as you said, the bug has been fixed in the latest
AIX version(s) (which I hope means it's also regression-tested, and
won't represent itself easily).
If someone really needs to do a "make dist" on an older AIX, he could
anyway install some version of GNU cp, no?
Thanks,
Stefano