NetBSD Problem Report #57807
From www@netbsd.org Mon Jan 1 19:33:37 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 3DED81A9238
for <gnats-bugs@gnats.NetBSD.org>; Mon, 1 Jan 2024 19:33:37 +0000 (UTC)
Message-Id: <20240101193335.D77B01A9239@mollari.NetBSD.org>
Date: Mon, 1 Jan 2024 19:33:35 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: #include <arpa/inet.h> spuriously defines le32enc/be32enc/... under _XOPEN_SOURCE=700
X-Send-Pr-Version: www-1.0
>Number: 57807
>Category: standards
>Synopsis: #include <arpa/inet.h> spuriously defines le32enc/be32enc/... under _XOPEN_SOURCE=700
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: standards-manager
>State: analyzed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Jan 01 19:35:00 +0000 2024
>Closed-Date:
>Last-Modified: Mon Sep 30 13:55:01 +0000 2024
>Originator: Taylor R Campbell
>Release: 9
>Organization:
The NetBE16 Foundation
>Environment:
>Description:
In an attempt to work around PR standards/57806, I tried defining _XOPEN_SOURCE=700 instead of _POSIX_C_SOURCE=200809L. But although this exposes ntohl/ntohs/htonl/htons, it _also_ exposes the nonstandard NetBSDisms be32enc and similar, which should be suppressed except if _NETBSD_SOURCE is also defined.
>How-To-Repeat:
$ cat pr.c
#define _XOPEN_SOURCE 700
#include <arpa/inet.h>
void be32dec(void) {}
$ make pr.o
cc -O2 -c pr.c
pr.c:3:6: error: conflicting types for ‘be32dec’
void be32dec(void) {}
^~~~~~~
In file included from /usr/include/amd64/endian.h:3:0,
from /usr/include/sys/types.h:98,
from /usr/include/arpa/inet.h:67,
from pr.c:2:
/usr/include/sys/endian.h:221:1: note: previous definition of ‘be32dec’ was here
__GEN_ENDIAN_DEC(32, be)
^
*** Error code 1
Stop.
make: stopped in /tmp/riastradh
>Fix:
Yes, please!
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Mon, 09 Sep 2024 18:17:40 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-10 and pullup-9
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57807 CVS commit: src/sys/sys
Date: Mon, 9 Sep 2024 18:17:14 +0000
Module Name: src
Committed By: riastradh
Date: Mon Sep 9 18:17:14 UTC 2024
Modified Files:
src/sys/sys: endian.h
Log Message:
sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
These are non-standard extensions, so they should not be exposed by,
e.g., _XOPEN_SOURCE=700.
PR standards/57807: #include <arpa/inet.h> spuriously defines
le32enc/be32enc/... under _XOPEN_SOURCE=700
To generate a diff of this commit:
cvs rdiff -u -r1.33 -r1.34 src/sys/sys/endian.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc:
Subject: Re: standards/57807: #include <arpa/inet.h> spuriously defines le32enc/be32enc/... under _XOPEN_SOURCE=700
Date: Thu, 12 Sep 2024 12:49:04 +0000
Followup tools build fix needed:
https://mail-index.netbsd.org/source-changes/2024/09/11/msg153276.html
Module Name: src
Committed By: christos
Date: Wed Sep 11 18:39:20 UTC 2024
Modified Files:
src/external/cddl/osnet/sys/sys: types.h
Log Message:
- Remove conditional code for HAVE_NBTOOLS_CONFIG_H. The variable name was
wrong anyway (it is HAVE_NBTOOL_CONFIG_H) so the code never worked as
intended.
- Do not define _NETBSD_SOURCE even temporarily. It broke the tools
build because <sys/types.h> includes <sys/endian.h> and with _NETBSD_SOUR=
CE
defined, this exposes the *enc and *dec functions which libctf redefines
if it thinks that the system does not define them (and nbtools_config.h
tells libctf that we are not defining them).
To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/external/cddl/osnet/sys/sys/types.h
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org,
Taylor R Campbell <riastradh@NetBSD.org>
Cc:
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Wed, 25 Sep 2024 15:28:48 +0900
On amd64 host with this commit for endian.h, cross-build for
evbarmv7hf-eb (at least) fails as follows:
````
% uname -a
NetBSD sakaizumii.local 10.99.12 NetBSD 10.99.12 (AMD64_NET_MPSAFE) #0:
Sun Sep 22 10:03:08 JST 2024
rin@sakaizumii.local:/home/rin/src/sys/arch/amd64/compile/AMD64_NET_MPSAFE
amd64
% head -1 /usr/include/sys/endian.h
/* $NetBSD: endian.h,v 1.35 2024/09/09 18:38:38 rillig Exp $ */
% cd src/tools/libctf && nbmake-evbarmv7hf-eb
...
In file included from
/home/rin/build.pullup-0925/tools/include/compat/nbtool_config.h:931,
from
/home/rin/src/tools/libctf/../../external/cddl/osnet/dist/
common/ctf/ctf_create.c:23:
/home/rin/src/tools/libctf/../compat/compat_defs.h:1148:22: error:
redefinition of 'be16enc'
...
````
This can be worked around by reverting rev 1.34 only.
The failure occurs because:
(1) During configure in tools/compat, _NETBSD_SOURCE is disabled.
(2) For other tools build, _NETBSD_SOURCE is defined.
Thoughts?
Thanks,
rin
On 2024/09/10 3:20, Taylor R Campbell wrote:
> The following reply was made to PR standards/57807; it has been noted by GNATS.
>
> From: "Taylor R Campbell" <riastradh@netbsd.org>
> To: gnats-bugs@gnats.NetBSD.org
> Cc:
> Subject: PR/57807 CVS commit: src/sys/sys
> Date: Mon, 9 Sep 2024 18:17:14 +0000
>
> Module Name: src
> Committed By: riastradh
> Date: Mon Sep 9 18:17:14 UTC 2024
>
> Modified Files:
> src/sys/sys: endian.h
>
> Log Message:
> sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE.
>
> These are non-standard extensions, so they should not be exposed by,
> e.g., _XOPEN_SOURCE=700.
>
> PR standards/57807: #include <arpa/inet.h> spuriously defines
> le32enc/be32enc/... under _XOPEN_SOURCE=700
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.33 -r1.34 src/sys/sys/endian.h
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Wed, 25 Sep 2024 14:33:07 +0700
Date: Wed, 25 Sep 2024 06:30:04 +0000 (UTC)
From: "Rin Okuyama via gnats" <gnats-admin@NetBSD.org>
Message-ID: <20240925063004.798201A923D@mollari.NetBSD.org>
| The failure occurs because:
| (1) During configure in tools/compat, _NETBSD_SOURCE is disabled.
| (2) For other tools build, _NETBSD_SOURCE is defined.
|
| Thoughts?
Ideally, _NETBSD_SOURCE wouldn't be defined at all for tools builds.
That it is resulted in the gross hack to fix the gmake tools build
(only ever built as a tool). I haven't looked, but something similar
might work in this case as well, but making _NETBSD_SOURCE not be
the default would be a much better solution.
That could be done by simply doing the tools builds with one of the
other feature macros defined, but which one? (and what value?)
So an easier way might just be to define a new macro like _NO_NETBSD_SOURCE
that <sys/featuretest.h> could use to avoid defining _NETBSD_SOURCE
when nothing else is defined, without committing to one of the others.
kre
State-Changed-From-To: needs-pullups->analyzed
State-Changed-By: rin@NetBSD.org
State-Changed-When: Wed, 25 Sep 2024 14:59:14 +0000
State-Changed-Why:
This breaks cross build, e.g., for evbarmv7hf-eb on amd64,
and therefore still cannot be pulled up yet.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Wed, 25 Sep 2024 22:29:53 +0000
> Date: Wed, 25 Sep 2024 15:28:48 +0900
> From: Rin Okuyama <rokuyama.rk@gmail.com>
>=20
> On amd64 host with this commit for endian.h, cross-build for
> evbarmv7hf-eb (at least) fails as follows:
>=20
> ````
> % uname -a
> NetBSD sakaizumii.local 10.99.12 NetBSD 10.99.12 (AMD64_NET_MPSAFE) #0:=20
> Sun Sep 22 10:03:08 JST 2024=20
> rin@sakaizumii.local:/home/rin/src/sys/arch/amd64/compile/AMD64_NET_MPSAF=
E=20
> amd64
> % head -1 /usr/include/sys/endian.h
> /* $NetBSD: endian.h,v 1.35 2024/09/09 18:38:38 rillig Exp $ */
> % cd src/tools/libctf && nbmake-evbarmv7hf-eb
> ...
> In file included from=20
> /home/rin/build.pullup-0925/tools/include/compat/nbtool_config.h:931,
> from=20
> /home/rin/src/tools/libctf/../../external/cddl/osnet/dist/
> common/ctf/ctf_create.c:23:
> /home/rin/src/tools/libctf/../compat/compat_defs.h:1148:22: error:=20
> redefinition of 'be16enc'
> ...
> ````
>=20
> This can be worked around by reverting rev 1.34 only.
Does this failure still reproduce after christos's fix to osnet
sys/types.h?
https://mail-index.netbsd.org/source-changes/2024/09/11/msg153276.html
> The failure occurs because:
> (1) During configure in tools/compat, _NETBSD_SOURCE is disabled.
> (2) For other tools build, _NETBSD_SOURCE is defined.
_NETBSD_SOURCE should absolutely never be defined during any part of
the tools build, and it was a mistake for it to appear in the osnet
sys/types.h hacks.
If christos's change doesn't fix it, can you find where _NETBSD_SOURCE
is getting defined so we can fix that too?
From: Robert Elz <kre@munnari.OZ.AU>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Rin Okuyama <rokuyama.rk@gmail.com>, gnats-bugs@netbsd.org,
netbsd-bugs@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Thu, 26 Sep 2024 06:23:23 +0700
Date: Wed, 25 Sep 2024 22:29:53 +0000
From: Taylor R Campbell <riastradh@NetBSD.org>
Message-ID: <20240925222957.A369A84D21@mail.netbsd.org>
| If christos's change doesn't fix it, can you find where _NETBSD_SOURCE
| is getting defined so we can fix that too?
It gets defined in <sys/featuretest.h> when none of the other
relevant symbols (_POSIX_C_SOURCE etc) are defined.
Things like the old gmake that are built as a tool don't define
any of those, so get __NetBSD_SOURCE ... we cannot really simply
pick one of the others to define for things like this, as there's
no particular reason they all need the same one.
kre
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: Rin Okuyama <rokuyama.rk@gmail.com>,
gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Thu, 26 Sep 2024 00:29:02 +0000
> Date: Thu, 26 Sep 2024 06:23:23 +0700
> From: Robert Elz <kre@munnari.OZ.AU>
>
> Date: Wed, 25 Sep 2024 22:29:53 +0000
> From: Taylor R Campbell <riastradh@NetBSD.org>
> Message-ID: <20240925222957.A369A84D21@mail.netbsd.org>
>
> | If christos's change doesn't fix it, can you find where _NETBSD_SOURCE
> | is getting defined so we can fix that too?
>
> It gets defined in <sys/featuretest.h> when none of the other
> relevant symbols (_POSIX_C_SOURCE etc) are defined.
>
> Things like the old gmake that are built as a tool don't define
> any of those, so get __NetBSD_SOURCE ... we cannot really simply
> pick one of the others to define for things like this, as there's
> no particular reason they all need the same one.
If old gmake doesn't use nbtool_config.h / compat_defs.h, then perhaps
it sounds like we should arrange to build old gmake with
-D_XOPEN_SOURCE=600 (and maybe the others too), just like
compat_defs.h. It is a bug for anything in tools to be built with
_NETBSD_SOURCE, even implicitly.
But it's not clear that's what's happening with tools/libctf, because
the excerpt quoted goes through nbtool_config.h, so it should pick up
the _XOPEN_SOURCE &c. definitions. So I'm puzzled where
_NETBSD_SOURCE could be coming from in that case.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Thu, 26 Sep 2024 16:14:19 +0700
Date: Thu, 26 Sep 2024 00:30:02 +0000 (UTC)
From: "Taylor R Campbell via gnats" <gnats-admin@NetBSD.org>
Message-ID: <20240926003002.CF0F91A923D@mollari.NetBSD.org>
| It is a bug for anything in tools to be built with
| _NETBSD_SOURCE, even implicitly.
Definitely agree.
| But it's not clear that's what's happening with tools/libctf,
Haven't looked at that one, but I will do.
kre
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org, kre@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Thu, 26 Sep 2024 19:10:53 +0900
On 2024/09/26 7:29, Taylor R Campbell wrote:
> Does this failure still reproduce after christos's fix to osnet
> sys/types.h?
>
> https://mail-index.netbsd.org/source-changes/2024/09/11/msg153276.html
>
>> The failure occurs because:
>> (1) During configure in tools/compat, _NETBSD_SOURCE is disabled.
>> (2) For other tools build, _NETBSD_SOURCE is defined.
>
> _NETBSD_SOURCE should absolutely never be defined during any part of
> the tools build, and it was a mistake for it to appear in the osnet
> sys/types.h hacks.
>
> If christos's change doesn't fix it, can you find where _NETBSD_SOURCE
> is getting defined so we can fix that too?
Ah, that's it!
With amd64-current host dated 2024-09-22, cross build for
evbarmv7hf-eb:
(1) succeeds for -current
(2) fails for netbsd-10, but
(3) succeeds (with X11) if above-mentioned commit is cherry-picked
(4) same situation for netbsd-9
So, we should pullup external/cddl/osnet/sys/sys/types.h
rev. 1.21 to netbsd-10 and -9, in order to keep cross build
possible for recent -current.
I will update the host side to today's current, and check other
target platforms (or trying all subdirs in tools??) for sure.
Thanks,
rin
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Taylor R Campbell <riastradh@NetBSD.org>, martin@NetBSD.org
Cc: gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org, kre@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Sat, 28 Sep 2024 18:38:21 +0900
As I reported, recent -current **host** with sys/sys/endian.h
rev 1.34 and later cannot cross-build **targets** without
external/cddl/osnet/sys/sys/types.h rev 1.21:
https://mail-index.netbsd.org/source-changes/2024/09/11/msg153276.html
So, it is really unfortunate if we don't have cddl/types.h
rev 1.21 in NetBSD 10.1.
With cherry-picking the cddl/types.h commit, I've confirmed for
netbsd-10 (both for `-c gcc` and `-c clang`):
(1) `tools/*` can be built. (Some are ports specific, or
gcc/clang specific.)
(2) Full build for amd64 and evbarm64 successfully completes
(with MKX11=yes).
(3) No new regression observed for amd64 and evbarm64.
(Only for `-c gcc` builds; there are some ATF failures for
`-c clang` builds before cherry-picking, even for -current.)
However, still, I'm not very sure whether this is safe to
pullup just before 10.1 release... Martin, how do you think?
Thanks,
rin
From: Martin Husemann <martin@duskware.de>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: Taylor R Campbell <riastradh@NetBSD.org>, martin@NetBSD.org,
gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org, kre@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Mon, 30 Sep 2024 15:42:42 +0200
On Sat, Sep 28, 2024 at 06:38:21PM +0900, Rin Okuyama wrote:
> However, still, I'm not very sure whether this is safe to
> pullup just before 10.1 release... Martin, how do you think?
Let's pull it up quickly, so any fallout shows up before we tag 10.1.
Martin
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Martin Husemann <martin@duskware.de>
Cc: Taylor R Campbell <riastradh@NetBSD.org>, martin@NetBSD.org,
gnats-bugs@netbsd.org, netbsd-bugs@NetBSD.org, kre@NetBSD.org
Subject: Re: PR/57807 CVS commit: src/sys/sys
Date: Mon, 30 Sep 2024 22:50:56 +0900
On 2024/09/30 22:42, Martin Husemann wrote:
> On Sat, Sep 28, 2024 at 06:38:21PM +0900, Rin Okuyama wrote:
>> However, still, I'm not very sure whether this is safe to
>> pullup just before 10.1 release... Martin, how do you think?
>
> Let's pull it up quickly, so any fallout shows up before we tag 10.1.
Thanks for your comment. I've sent it as:
[pullup-10 #923] [URGENT] Fix cross-build on recent -current with
sys/endian.h rev 1.34 and later
Thanks,
rin
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home