GNU bug report logs - #50972
src/ls.c fails to build when __GNUC_PREREQ is not defined (e.g., OpenBSD)

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 50972 in the body.
You can then email your comments to 50972 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: Brian Callahan <bcallah <at> posteo.net>
To: bug-coreutils <at> gnu.org
Subject: src/ls.c fails to build when __GNUC_PREREQ is not defined (e.g., OpenBSD)
Date: Sat, 02 Oct 2021 14:44:32 +0000

Hello --

I am the GNU coreutils package maintainer for OpenBSD.
While updating the OpenBSD package to 9.0, the build errored out while 
compiling src/ls.c with the following error message:

src/ls.c:2276:6: error: function-like macro '__GNUC_PREREQ' is not 
defined

I noticed that there are some #ifdefs defining and using the macro in 
the lib/ directory but clearly the definition is not reaching into src/.

OpenBSD has a __GNUC_PREREQ__ macro defined in <sys/cdefs.h> but not the 
__GNUC_PREREQ macro.

If the preprocessor checks and associated pragmas are removed from 
src/ls.c then it builds OK. OpenBSD package builders use clang 11.1.0 
and clang does not trigger the bogus warnings that these 
__GNUC_PREREQ-wrapped pragmas are defending against. Obviously that is 
not a universal fix, just a data point.

Once this fix is done, the rest of coreutils-9.0 builds and works OK. 
There are no test failures for coreutils-9.0 on 
x86_64-unknown-openbsd7.0

Thanks.

~Brian

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Brian Callahan <bcallah <at> posteo.net>
Cc: 50972 <at> debbugs.gnu.org
Subject: Re: bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not
 defined (e.g., OpenBSD)
Date: Sat, 2 Oct 2021 19:07:04 -0700

On 10/2/21 7:44 AM, Brian Callahan wrote:
> Once this fix is done, the rest of coreutils-9.0 builds and works OK.

Thanks for letting us know, as it's been a while since I tried building 
coreutils on OpenBSD. I just now tried it on OpenBSD 6.9 and found some 
other problems that were easy to lose sight of in the blizzard of false 
alarms that clang emits on OpenBSD 6.9. I fixed all the problems I 
noticed and installed the following patches into coreutils:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4cfd48481da0486e2bad193495bc38e7d5ead7e4
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b31a6a09ad0caddce29729f8c9bc4c36c073b7b6
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5b43b8e9ce215864001314f92097584bceb71b58

These rely on the following OpenBSD-related patches to Gnulib, which I 
installed earlier today:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9bcd248da1ef25b3ff3431248f53401e1123d74f
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dd0af10fa597a95ffe5f4f110ef5edefc2f680bc

The first patch listed above should fix the problem you mentioned; you 
might want to look at the other patches as well.

By the way, how do you deal with all those false positives from clang? 
Do you suppress them with CFLAGS? I'm referring to the many warnings 
like "comparison is always true due to limited range of data type" and a 
few "integer overflow in expression" warnings. With so many false alarms 
I wouldn't be surprised if people stopped paying attention to compiler 
warnings even if they're valid.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Brian Callahan <bcallah <at> posteo.net>
Cc: 50972 <at> debbugs.gnu.org
Subject: Re: bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not
 defined (e.g., OpenBSD)
Date: Sun, 3 Oct 2021 12:38:05 +0100

On 03/10/2021 03:07, Paul Eggert wrote:
> On 10/2/21 7:44 AM, Brian Callahan wrote:
>> Once this fix is done, the rest of coreutils-9.0 builds and works OK.
> 
> Thanks for letting us know, as it's been a while since I tried building
> coreutils on OpenBSD. I just now tried it on OpenBSD 6.9 and found some
> other problems that were easy to lose sight of in the blizzard of false
> alarms that clang emits on OpenBSD 6.9. I fixed all the problems I
> noticed and installed the following patches into coreutils:
> 
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4cfd48481da0486e2bad193495bc38e7d5ead7e4
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b31a6a09ad0caddce29729f8c9bc4c36c073b7b6
> https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5b43b8e9ce215864001314f92097584bceb71b58
> 
> These rely on the following OpenBSD-related patches to Gnulib, which I
> installed earlier today:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=9bcd248da1ef25b3ff3431248f53401e1123d74f
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dd0af10fa597a95ffe5f4f110ef5edefc2f680bc
> 
> The first patch listed above should fix the problem you mentioned; you
> might want to look at the other patches as well.
> 
> By the way, how do you deal with all those false positives from clang?
> Do you suppress them with CFLAGS? I'm referring to the many warnings
> like "comparison is always true due to limited range of data type" and a
> few "integer overflow in expression" warnings. With so many false alarms
> I wouldn't be surprised if people stopped paying attention to compiler
> warnings even if they're valid.

Thanks for doing all that.
I'm confused as to why some functions need _Noreturn and some don't.
For example why does cleanup_fatal() in csplit.c need it since it calls exit()?
Does GCC not propagate the noreturn from exit to cleanup_fatal()?

In general I see this may introduce warnings on older systems,
but that's fine as dev is generally done on newer compilers,
and non dev builds on older systems will not have -Werror set.

thanks,
Pádraig

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

From: Brian Callahan <bcallah <at> posteo.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 50972 <at> debbugs.gnu.org
Subject: Re: bug#50972: src/ls.c fails to build when
 __GNUC_PREREQ is not defined (e.g., OpenBSD)
Date: Sun, 03 Oct 2021 03:14:52 +0000

Hi Paul --

On 10/02/2021 10:07 PM, Paul Eggert wrote:
> 
> The first patch listed above should fix the problem you mentioned; you
> might want to look at the other patches as well.

Much appreciated. Can confirm the tip of the tree builds OOTB now.

> By the way, how do you deal with all those false positives from clang?
> Do you suppress them with CFLAGS? I'm referring to the many warnings
> like "comparison is always true due to limited range of data type" and
> a few "integer overflow in expression" warnings. With so many false
> alarms I wouldn't be surprised if people stopped paying attention to
> compiler warnings even if they're valid.

OpenBSD 7.0 (which is ready to go, just hasn't had an official 
announcement) ships with clang 11.1.0, whereas OpenBSD 6.9 ships with 
clang 10.0.1. I did not try to build coreutils-9.0 on 6.9 but on 7.0 
there are virtually no warnings during the build (even before these 
fixes).

I can send you a build log offlist if you'd like to see what the 7.0 
build looks like.

~Brian

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Brian Callahan <bcallah <at> posteo.net>
Cc: 50972 <at> debbugs.gnu.org
Subject: Re: bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not
 defined (e.g., OpenBSD)
Date: Sun, 3 Oct 2021 10:35:50 -0700

On 10/3/21 4:38 AM, Pádraig Brady wrote:
> I'm confused as to why some functions need _Noreturn and some don't.

Yes, it's a bit of a pain. _Noreturn is useful on extern functions, 
since otherwise GCC typically won't know the function doesn't return. On 
static functions, though, _Noreturn generally isn't needed since GCC can 
figure it out.

Unfortunately, I needed to keep _Noreturn on three static functions in 
Coreutils to pacify GCC into not generating the following false alarms. 
Today I reported this issue as GCC bug 102578 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102578>.

  src/csplit.c: In function 'xalloc_die':
  src/csplit.c:235:1: error: 'noreturn' function does return [-Werror]
    235 | }
        | ^

  src/sort.c: In function 'open_temp':
  src/sort.c:1206:7: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
   1206 |       async_safe_die (errno, "couldn't execute compress 
program (with -d)");
        | 
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  src/sort.c:1208:5: note: here
   1208 |     default:
        |     ^~~~~~~

  src/test.c: In function 'find_int':
  src/test.c:161:1: error: control reaches end of non-void function 
[-Werror=return-type]
    161 | }
        | ^

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Brian Callahan <bcallah <at> posteo.net>
Cc: 50972 <at> debbugs.gnu.org
Subject: Re: bug#50972: src/ls.c fails to build when __GNUC_PREREQ is not
 defined (e.g., OpenBSD)
Date: Sun, 3 Oct 2021 10:42:46 -0700

On 10/2/21 8:14 PM, Brian Callahan wrote:
> I can send you a build log offlist if you'd like to see what the 7.0 
> build looks like.

It sounds like the more-recent clang has fixed most of the false alarms. 
It'd probably be a more-efficient use of our time for us to wait until 
7.0 is out, so that I can then run 7.0 in a VM myself (as debugging via 
email is a pain) and look into the remaining diagnostics. If recent 
experience is any guide they'll be false alarms too, so this isn't urgent.

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

From: Brian Callahan <bcallah <at> posteo.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 50972 <at> debbugs.gnu.org
Subject: Re: bug#50972: src/ls.c fails to build when
 __GNUC_PREREQ is not defined (e.g., OpenBSD)
Date: Sun, 03 Oct 2021 18:25:33 +0000

On 10/03/2021 01:42 PM, Paul Eggert wrote:
> On 10/2/21 8:14 PM, Brian Callahan wrote:
>> I can send you a build log offlist if you'd like to see what the 7.0 
>> build looks like.
> 
> It sounds like the more-recent clang has fixed most of the false
> alarms. It'd probably be a more-efficient use of our time for us to
> wait until 7.0 is out, so that I can then run 7.0 in a VM myself (as
> debugging via email is a pain) and look into the remaining
> diagnostics. If recent experience is any guide they'll be false alarms
> too, so this isn't urgent.

Sounds good. Thanks again for the quick fix.

~Brian

Previous Next

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