Jim Meyering <[EMAIL PROTECTED]> wrote:
> For the record, here's what I did:
>
> Simulate the lack of openat functions:
> ac_cv_func_openat=no ./configure && make && make check
> All tests passed.
>
> Next, pretend we don't have /proc/self/fd support either, by changing
> the openat-emulation code to use nonexistent /proc/self/FD:
> perl -pi -e 's,/proc/self/fd,/proc/self/FD,' lib/openat-proc.c \
> tests/du/long-from-unreadable tests/rm/inaccessible
>
> That passed all tests, too, and gave the strace results that looked
> so different from yours.
Actually, Michael pointed out that your strace includes an fstatat call
(failing with ENOSYS, no less), which suggests you're using a new-enough
version.
I dug a little deeper and think I have identified the problem. I suspect
that your system has a working openat function and that coreutils detects
it, but that your fstatat function always returns ENOSYS.
The openat module's configure-time test checks only for the existence
of the openat function. If that test succeeds on your system, yet it
lacks fstatat, then that would explain what's happening.
To support such a system you have a choice:
1) easy: turn off all openat support. i.e., build like this:
ac_cv_func_openat=no ./configure
2) more work: add a configure-time test for a working fstatat, and
if it's not available, link with the replacement function that is
currently included unconditionally via the definition in openat.c.
Since this is for a kernel that is old, but not *that* old, (i.e., the
problem affects only the few kernels, that had incomplete openat support)
spending time on #2 does not seem worthwhile to me.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
