GNU bug report logs - #39929
coreutils-8.32 fails to build on aarch64

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39929 in the body.
You can then email your comments to 39929 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: bug-coreutils <at> gnu.org
Subject: coreutils-8.32 fails to build on aarch64
Date: Thu, 05 Mar 2020 17:21:57 +0100

While trying to build coreutils-8.32 for Fedora on aarch64, I got the following
compilation failure:

../src/ls.c: In function 'print_dir':
../src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this function); did you mean 'SYS_getdents64'?
 3026 |           if (syscall (SYS_getdents, dirfd (dirp), NULL, 0) == -1
      |                        ^~~~~~~~~~~~
      |                        SYS_getdents64
../src/ls.c:3026:24: note: each undeclared identifier is reported only once for each function it appears in


Sorry for reporting it late.  I tried to build 8.31.90-cc4c and 8.31.99-f2034
in Fedora copr but forgot to enable aarch64, so these builds succeeded  :-/

Kamil

Message #8 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Thu, 5 Mar 2020 17:39:23 +0000

[Message part 1 (text/plain, inline)]

On 05/03/2020 16:21, Kamil Dudka wrote:
> While trying to build coreutils-8.32 for Fedora on aarch64, I got the following
> compilation failure:
> 
> ../src/ls.c: In function 'print_dir':
> ../src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this function); did you mean 'SYS_getdents64'?
>   3026 |           if (syscall (SYS_getdents, dirfd (dirp), NULL, 0) == -1
>        |                        ^~~~~~~~~~~~
>        |                        SYS_getdents64
> ../src/ls.c:3026:24: note: each undeclared identifier is reported only once for each function it appears in
> 
> 
> Sorry for reporting it late.  I tried to build 8.31.90-cc4c and 8.31.99-f2034
> in Fedora copr but forgot to enable aarch64, so these builds succeeded  :-/

Ah well.
Does the attached address this for you.

[coreutils-getdents64.patch (text/x-patch, attachment)]

Message #11 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Thu, 5 Mar 2020 13:43:09 -0800

On 3/5/20 9:39 AM, Pádraig Brady wrote:
> Ah well.
> Does the attached address this for you.

Eeeuw.

Why is this code even there at all? If readdir(3) says that the current 
directory has no entries, shouldn't 'ls' just say that? Why should ls 
report an error simply because the current directory isn't reachable 
from the filesystem? Whether the current directory is unreachable has 
nothing to do with ls's job, which is to report whether the current 
directory has entries.

Message #14 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Thu, 5 Mar 2020 17:27:16 -0800

[Message part 1 (text/plain, inline)]

On 3/5/20 1:43 PM, Paul Eggert wrote:

> Why is this code even there at all? If readdir(3) says that the current 
> directory has no entries, shouldn't 'ls' just say that? Why should ls 
> report an error simply because the current directory isn't reachable 
> from the filesystem? Whether the current directory is unreachable has 
> nothing to do with ls's job, which is to report whether the current 
> directory has entries.

Attached is a proposed patch to fix this.

[0001-ls-restore-8.31-behavior-on-removed-directories.patch (text/x-patch, attachment)]

Message #17 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady
 <P <at> draigBrady.com>, Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Fri, 6 Mar 2020 08:31:29 +0100

On 2020-03-06 02:27, Paul Eggert wrote:
> On 3/5/20 1:43 PM, Paul Eggert wrote:
>
>> Why is this code even there at all? If readdir(3) says that the current
>> directory has no entries, shouldn't 'ls' just say that? Why should ls
>> report an error simply because the current directory isn't reachable
>> from the filesystem? Whether the current directory is unreachable has
>> nothing to do with ls's job, which is to report whether the current
>> directory has entries.
>
> Attached is a proposed patch to fix this.

I tend to agree (now): returning an error when there was none seems at least
unlucky.  Sorry I didn't comment in the original discussion.

> diff --git a/tests/ls/removed-directory.sh b/tests/ls/removed-directory.sh

That test was also added in commit 05a99f7d7f8e, so the the description
at the top does not match after reverting:

  #!/bin/sh
  # If ls is asked to list a removed directory (e.g. the parent process's
  # current working directory that has been removed by another process), it
  # emits an error message.

s/emits/shall not emit/

Thanks & have a nice day,
Berny

Message #20 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Pádraig Brady
 <P <at> draigBrady.com>, Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Fri, 6 Mar 2020 08:36:07 +0100

On 2020-03-06 08:31, Bernhard Voelker wrote:
> On 2020-03-06 02:27, Paul Eggert wrote:
>> On 3/5/20 1:43 PM, Paul Eggert wrote:
>>
>>> Why is this code even there at all? If readdir(3) says that the current
>>> directory has no entries, shouldn't 'ls' just say that? Why should ls
>>> report an error simply because the current directory isn't reachable
>>> from the filesystem? Whether the current directory is unreachable has
>>> nothing to do with ls's job, which is to report whether the current
>>> directory has entries.
>>
>> Attached is a proposed patch to fix this.
> 
> I tend to agree (now): returning an error when there was none seems at least
> unlucky.  Sorry I didn't comment in the original discussion.
> 
>> diff --git a/tests/ls/removed-directory.sh b/tests/ls/removed-directory.sh
> 
> That test was also added in commit 05a99f7d7f8e, so the the description
> at the top does not match after reverting:
> 
>   #!/bin/sh
>   # If ls is asked to list a removed directory (e.g. the parent process's
>   # current working directory that has been removed by another process), it
>   # emits an error message.
> 
> s/emits/shall not emit/

P.S. Also the check for $host_triplet containing 'linux' in test is:
a) no longer needed, and
b) looks like a good argument to revert 05a99f7d7f8e, because it introduced
different (and user-visible) behavior just because of the platform.

Have a nice day,
Berny

Message #23 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Fri, 06 Mar 2020 09:48:15 +0100

On Thursday, March 5, 2020 6:39:23 PM CET Pádraig Brady wrote:
> On 05/03/2020 16:21, Kamil Dudka wrote:
> > While trying to build coreutils-8.32 for Fedora on aarch64, I got the
> > following compilation failure:
> > 
> > ../src/ls.c: In function 'print_dir':
> > ../src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this
> > function); did you mean 'SYS_getdents64'?> 
> >   3026 |           if (syscall (SYS_getdents, dirfd (dirp), NULL, 0) == -1
> >   
> >        |                        ^~~~~~~~~~~~
> >        |                        SYS_getdents64
> > 
> > ../src/ls.c:3026:24: note: each undeclared identifier is reported only
> > once for each function it appears in
> > 
> > 
> > Sorry for reporting it late.  I tried to build 8.31.90-cc4c and
> > 8.31.99-f2034 in Fedora copr but forgot to enable aarch64, so these
> > builds succeeded  :-/
> Ah well.
> Does the attached address this for you.

Thanks!  I confirm that the ls/removed-directory test passes with the patch
on all architectures that Fedora builds for:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42242960

Kamil

Message #26 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Kamil Dudka <kdudka <at> redhat.com>,
 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Fri, 6 Mar 2020 10:48:18 +0000

On 05/03/2020 21:43, Paul Eggert wrote:
> On 3/5/20 9:39 AM, Pádraig Brady wrote:
>> Ah well.
>> Does the attached address this for you.
> 
> Eeeuw.
> 
> Why is this code even there at all? If readdir(3) says that the current
> directory has no entries, shouldn't 'ls' just say that? Why should ls
> report an error simply because the current directory isn't reachable
> from the filesystem? Whether the current directory is unreachable has
> nothing to do with ls's job, which is to report whether the current
> directory has entries.

I'm not very attached to the new behavior so feel free to apply this.
As per the original discussion, the change was made to distinguish
unreachable directories from empty directories.
Unreachable dirs are not common, but it seems useful for the user
to know they're in one

cheers,
Pádraig

Message #29 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Pádraig Brady <P <at> draigBrady.com>,
 Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Sat, 7 Mar 2020 10:32:18 -0800

[Message part 1 (text/plain, inline)]

On 3/5/20 11:36 PM, Bernhard Voelker wrote:
>> s/emits/shall not emit/
> P.S. Also the check for $host_triplet containing 'linux' in test is:
> a) no longer needed, ...

Thanks for catching those; I installed the attached further patch.

[0001-ls-improve-removed-directory-test.patch (text/x-patch, attachment)]

Message #34 received at 39929 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Kamil Dudka <kdudka <at> redhat.com>, 39929 <at> debbugs.gnu.org
Subject: Re: bug#39929: coreutils-8.32 fails to build on aarch64
Date: Sat, 7 Mar 2020 12:33:25 -0800

On 3/6/20 2:48 AM, Pádraig Brady wrote:
> 
> I'm not very attached to the new behavior so feel free to apply this.
> As per the original discussion, the change was made to distinguish
> unreachable directories from empty directories.
> Unreachable dirs are not common, but it seems useful for the user
> to know they're in one

Thanks, I applied the patch. My feeling is that 'ls' is about listing directory 
contents, which is a different issue than reachability. A user wanting to know 
whether they're in an unreachable directory can use a reachability-tester, like 
'pwd'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.