NetBSD Problem Report #58674
From www@netbsd.org Tue Sep 17 00:15:26 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)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 9569F1A9246
for <gnats-bugs@gnats.NetBSD.org>; Tue, 17 Sep 2024 00:15:26 +0000 (UTC)
Message-Id: <20240917001524.BF6E91A9247@mollari.NetBSD.org>
Date: Tue, 17 Sep 2024 00:15:24 +0000 (UTC)
From: david@gutteridge.ca
Reply-To: david@gutteridge.ca
To: gnats-bugs@NetBSD.org
Subject: HEAD fails to build tools on recent Linux (Fedora 40)
X-Send-Pr-Version: www-1.0
>Number: 58674
>Category: lib
>Synopsis: HEAD fails to build tools on recent Linux (Fedora 40)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kre
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Sep 17 00:20:00 +0000 2024
>Closed-Date: Sun Dec 15 23:04:11 +0000 2024
>Last-Modified: Sun Dec 15 23:04:11 +0000 2024
>Originator: David H. Gutteridge
>Release: HEAD (10.99.12)
>Organization:
TNF
>Environment:
Linux arcusxiii.nonus-porta.net 6.10.10-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 12 18:26:09 UTC 2024 x86_64 GNU/Linux
>Description:
"./build.sh -U -m amd64 -j 2 tools" fails on Fedora 40 initially like
so:
# compile date/date.lo
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/disciple/NetBSD/src/tools/compat/obj -I/home/disciple/NetBSD/src/tools/compat/obj/include -I/home/disciple/NetBSD/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/home/disciple/NetBSD/src/tools/date/../../bin/date -c -o date.lo.o -Wno-format-nonliteral /home/disciple/NetBSD/src/tools/date/../../bin/date/date.c
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c: In function 'main':
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c:115:37: error: implicit declaration of function 'strptime'; did you mean 'strftime'? [-Wimplicit-function-declaration]
115 | p = strptime(optarg, "%Y%m%d", &tm);
| ^~~~~~~~
| strftime
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c:115:35: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
115 | p = strptime(optarg, "%Y%m%d", &tm);
| ^
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c: In function 'setthetime':
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c:231:19: error: assignment to 'const char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
231 | t = strptime(p, fmt, lt);
| ^
To work around this, I added this hack (not where we'd do this, I imagine):
RCS file: /cvsroot/src/tools/date/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- Makefile 27 May 2021 08:41:35 -0000 1.2
+++ Makefile 16 Sep 2024 18:23:46 -0000
@@ -19,4 +19,6 @@
COMPATOBJ!= cd ${NETBSDSRCDIR}/tools/compat && ${PRINTOBJDIR}
.-include "${COMPATOBJ}/defs.mk"
+HOST_CFLAGS+= -D_XOPEN_SOURCE
+
.include "${.CURDIR}/../Makefile.host"
That gets me past that error and on to more in the same tool.
cc -O -D_XOPEN_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/disciple/NetBSD/src/tools/compat/obj -I/home/disciple/NetBSD/src/tools/compat/obj/include -I/home/disciple/NetBSD/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/home/disciple/NetBSD/src/tools/date/../../bin/date -c -o date.lo.o -Wno-format-nonliteral /home/disciple/NetBSD/src/tools/date/../../bin/date/date.c
In file included from /home/disciple/NetBSD/src/tools/compat/obj/nbtool_config.h:934,
from /home/disciple/NetBSD/src/tools/date/../../bin/date/date.c:33:
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'be16enc':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1153:13: error: implicit declaration of function 'htobe16' [-Wimplicit-function-declaration]
1153 | u = hto ## endian ## bits (u); \
| ^~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1157:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
1157 | __GEN_ENDIAN_ENC(16, be)
| ^~~~~~~~~~~~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'be32enc':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1153:13: error: implicit declaration of function 'htobe32' [-Wimplicit-function-declaration]
1153 | u = hto ## endian ## bits (u); \
| ^~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1160:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
1160 | __GEN_ENDIAN_ENC(32, be)
| ^~~~~~~~~~~~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'be64enc':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1153:13: error: implicit declaration of function 'htobe64' [-Wimplicit-function-declaration]
1153 | u = hto ## endian ## bits (u); \
| ^~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1163:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
1163 | __GEN_ENDIAN_ENC(64, be)
| ^~~~~~~~~~~~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'le16enc':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1153:13: error: implicit declaration of function 'htole16' [-Wimplicit-function-declaration]
1153 | u = hto ## endian ## bits (u); \
| ^~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1166:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
1166 | __GEN_ENDIAN_ENC(16, le)
| ^~~~~~~~~~~~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'le32enc':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1153:13: error: implicit declaration of function 'htole32' [-Wimplicit-function-declaration]
1153 | u = hto ## endian ## bits (u); \
| ^~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1169:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
1169 | __GEN_ENDIAN_ENC(32, le)
| ^~~~~~~~~~~~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'le64enc':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1153:13: error: implicit declaration of function 'htole64' [-Wimplicit-function-declaration]
1153 | u = hto ## endian ## bits (u); \
| ^~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1172:1: note: in expansion of macro '__GEN_ENDIAN_ENC'
1172 | __GEN_ENDIAN_ENC(64, le)
| ^~~~~~~~~~~~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'be16dec':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1185:22: error: implicit declaration of function 'be16toh' [-Wimplicit-function-declaration]
1185 | __GEN_ENDIAN_DEC(16, be)
| ^~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1182:16: note: in definition of macro '__GEN_ENDIAN_DEC'
1182 | return endian ## bits ## toh (u); \
| ^~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'be32dec':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1188:22: error: implicit declaration of function 'be32toh' [-Wimplicit-function-declaration]
1188 | __GEN_ENDIAN_DEC(32, be)
| ^~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1182:16: note: in definition of macro '__GEN_ENDIAN_DEC'
1182 | return endian ## bits ## toh (u); \
| ^~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'be64dec':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1191:22: error: implicit declaration of function 'be64toh' [-Wimplicit-function-declaration]
1191 | __GEN_ENDIAN_DEC(64, be)
| ^~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1182:16: note: in definition of macro '__GEN_ENDIAN_DEC'
1182 | return endian ## bits ## toh (u); \
| ^~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'le16dec':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1194:22: error: implicit declaration of function 'le16toh' [-Wimplicit-function-declaration]
1194 | __GEN_ENDIAN_DEC(16, le)
| ^~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1182:16: note: in definition of macro '__GEN_ENDIAN_DEC'
1182 | return endian ## bits ## toh (u); \
| ^~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'le32dec':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1197:22: error: implicit declaration of function 'le32toh' [-Wimplicit-function-declaration]
1197 | __GEN_ENDIAN_DEC(32, le)
| ^~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1182:16: note: in definition of macro '__GEN_ENDIAN_DEC'
1182 | return endian ## bits ## toh (u); \
| ^~~~~~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h: In function 'le64dec':
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1200:22: error: implicit declaration of function 'le64toh' [-Wimplicit-function-declaration]
1200 | __GEN_ENDIAN_DEC(64, le)
| ^~
/home/disciple/NetBSD/src/tools/compat/compat_defs.h:1182:16: note: in definition of macro '__GEN_ENDIAN_DEC'
1182 | return endian ## bits ## toh (u); \
| ^~~~~~
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c: In function 'main':
/home/disciple/NetBSD/src/tools/date/../../bin/date/date.c:155:31: error: implicit declaration of function 'setenv'; did you mean 'getenv'? [-Wimplicit-function-declaration]
155 | (void)setenv("TZ", "UTC0", 1);
| ^~~~~~
| getenv
*** Failed target: date.lo
In general, it seems like builds wouldn't work with recent Linux
distros, such as Fedora 40, which has (for example)
-Wimplicit-function-declaration baked on (as an error) by default.
Looking in tools/compat/compat_defs.h, I find some things seemingly
contradictory:
/*
* On NetBSD, ensure that _NETBSD_SOURCE does not get defined, so that
* accidental attempts to use NetBSD-specific features instead of more
* portable features is likely to be noticed when the tools are built
* on NetBSD. Define enough other feature test macros to expose the
* features we need.
*/
#ifdef __NetBSD__
#define _ISOC99_SOURCE
#define _POSIX_SOURCE 1
#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE 600
#endif /* __NetBSD__ */
/*
* Linux: <features.h> turns on _POSIX_SOURCE by default, even though the
* program (not the OS) should do that. Preload <features.h> and
* then override some of the feature test macros.
*/
#if defined(__linux__) && HAVE_FEATURES_H
#include <features.h>
#undef _POSIX_SOURCE
#undef _POSIX_C_SOURCE
#define __USE_ISOC99 1
#endif /* __linux__ && HAVE_FEATURES_H */
So, on NetBSD the idea is those various defines are required
universally, but on Linux "the program ... should do that". Which is it?
(Yes, I know _XOPEN_SOURCE isn't touched there.)
I haven't got to looking at those undefined conversion macros yet.
Dave
>How-To-Repeat:
As above.
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: kre@NetBSD.org
State-Changed-When: Tue, 17 Sep 2024 11:33:18 +0000
State-Changed-Why:
Please try again with src/bin/date/date.c from HEAD as of now or later.
Let us know if (without any attempts to set XOPEN_SOURCE or similar) the
tools build now on your system.
From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/bin/date
Date: Tue, 17 Sep 2024 11:30:11 +0000
Module Name: src
Committed By: kre
Date: Tue Sep 17 11:30:11 UTC 2024
Modified Files:
src/bin/date: date.c
Log Message:
PR lib/58674 (and I suspect, several others)
Stop expecting strptime(3) in the tools build, it is an XSI
function, and the tools builds do not set up the environment
to expect XSI functions to be available.
This means dropping support for the -f option in the tools date
(which shouldn't matter, -f sets the format for the string used
to set the time, which the tools date does not support), and
open coding parsing for the -d option in the tools build.
There should be no changes to the date(1) that is installed in /bin
As a (minor) benefit, the tools -d support has become somewhat
more flexible than the previous simple strptime() implementation
allowed, and also does better error checking (no more Feb 30 etc).
Note: no change to the usage message, if -f is passed to the tools
date it will elicit a usage which says that -f is supported...
(that's just laziness...)
To generate a diff of this commit:
cvs rdiff -u -r1.67 -r1.68 src/bin/date/date.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: feedback->open
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Tue, 17 Sep 2024 13:19:50 +0000
State-Changed-Why:
Feedback provided, another similar issue found.
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/58674 (HEAD fails to build tools on recent Linux (Fedora 40))
Date: Tue, 17 Sep 2024 09:18:59 -0400
Thanks for the fix!
The next issue is much the same, another function guarded by
XOPEN_SOURCE, this time in sed:
/home/disciple/NetBSD/src/tools/sed/../../usr.bin/sed/process.c: In
function 'lputs':
/home/disciple/NetBSD/src/tools/sed/../../usr.bin/sed/process.c:636:41:
error: implicit declaration of function 'wcwidth'
[-Wimplicit-function-declaration]
636 | width = (size_t)wcwidth(wc);
| ^~~~~~~
Dave
From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/usr.bin/sed
Date: Tue, 17 Sep 2024 13:34:08 +0000
Module Name: src
Committed By: kre
Date: Tue Sep 17 13:34:08 UTC 2024
Modified Files:
src/usr.bin/sed: process.c
Log Message:
PR lib/58674
When building the tools version of sed, treat all wide characters
as if they occupy just one column for the purposes of sed's 'l'
command (which it is very unlikely to be used from the tools sed).
wdwidth() is another XSI function, not necessarily available everywhere.
To generate a diff of this commit:
cvs rdiff -u -r1.53 -r1.54 src/usr.bin/sed/process.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: kre@NetBSD.org
State-Changed-When: Tue, 17 Sep 2024 13:35:16 +0000
State-Changed-Why:
Please try again with src/usr.bin/sed in HEAD as it is now.
This one is a really kludgy fix, but should allow the build to continue.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/58674: HEAD fails to build tools on recent Linux (Fedora 40)
Date: Tue, 17 Sep 2024 20:52:16 +0700
Date: Tue, 17 Sep 2024 00:20:00 +0000 (UTC)
From: david@gutteridge.ca
Message-ID: <20240917002000.AD1831A9244@mollari.NetBSD.org>
| So, on NetBSD the idea is those various defines are required
| universally, but on Linux "the program ... should do that". Which is it?
Strictly, all programs should say what standard(s) they are being
written for, and so which the compiler should apply.
However, for normal NetBSD applications we simply set __NetBSD_SOURCE__
and allow everything conceivable to be visible (and so used), and then
make sure the code doesn't use anything that exposes in incompatible ways.
The #ifdef __NetBSD__ section you showed is attempting to undo that for
tools builds, so we can (hopefully) catch things in the tools build before
they get to foreign systems ... but our headers aren't all perfect in
what they actually expose, when __NetBSD_SOURCE__ isn't defined.
kre
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/58674: HEAD fails to build tools on recent Linux (Fedora 40)
Date: Wed, 18 Sep 2024 21:29:00 -0400
After the fix to sed, I encountered one more (and final) issue, with
gmake. It wants to use bsd_signal(3), which is also guarded on modern
glibc as an X/Open feature in certain contexts. I kludged around that
and then had a complete tools build.
Comparing the tools build of gmake vs. the build of the (much newer)
version in pkgsrc, the latter doesn't fail, as it doesn't set via
configure that it has bsd_signal(3) present, unlike tools, apparently.
I haven't looked into why that is (e.g., is it something overridden
locally in NetBSD src, or gmake has improved its configury).
Dave
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: lib/58674: HEAD fails to build tools on recent Linux (Fedora 40)
Date: Wed, 18 Sep 2024 21:34:21 -0400
On Tue, 2024-09-17 at 13:55 +0000, Robert Elz via gnats wrote:
> The following reply was made to PR lib/58674; it has been noted by
> GNATS.
>=20
> From: Robert Elz <kre@munnari.OZ.AU>
> To: gnats-bugs@netbsd.org
> Cc:=20
> Subject: Re: lib/58674: HEAD fails to build tools on recent Linux
> (Fedora 40)
> Date: Tue, 17 Sep 2024 20:52:16 +0700
>=20
> =C2=A0=C2=A0=C2=A0=C2=A0 Date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Tue, 17 Sep 2024 00:20:00 +0000 (UTC)
> =C2=A0=C2=A0=C2=A0=C2=A0 From:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
david@gutteridge.ca
> =C2=A0=C2=A0=C2=A0=C2=A0 Message-ID:=C2=A0 <20240917002000.AD1831A9244@mo=
llari.NetBSD.org>
> =C2=A0
> =C2=A0=C2=A0 | So, on NetBSD the idea is those various defines are requir=
ed
> =C2=A0=C2=A0 | universally, but on Linux "the program ... should do that"=
. Which
> is it?
> =C2=A0
> =C2=A0Strictly, all programs should say what standard(s) they are being
> =C2=A0written for, and so which the compiler should apply.
> =C2=A0
> =C2=A0However, for normal NetBSD applications we simply set
> __NetBSD_SOURCE__
> =C2=A0and allow everything conceivable to be visible (and so used), and
> then
> =C2=A0make sure the code doesn't use anything that exposes in incompatibl=
e
> ways.
> =C2=A0
> =C2=A0The #ifdef __NetBSD__ section you showed is attempting to undo that
> for
> =C2=A0tools builds, so we can (hopefully) catch things in the tools build
> before
> =C2=A0they get to foreign systems ... but our headers aren't all perfect =
in
> =C2=A0what they actually expose, when __NetBSD_SOURCE__ isn't defined.
I see, so it's like there are two layers to this. We're trying to avoid
NetBSD-specific features, but XOPEN_SOURCE is one of the things then
set, so if those are indeed correct, we still won't catch everything
unexpected on other platforms.
Dave
State-Changed-From-To: feedback->open
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Thu, 19 Sep 2024 01:41:28 +0000
State-Changed-Why:
Further testing and feedback provided; remaining issue with gmake.
From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/sys/sys
Date: Thu, 19 Sep 2024 13:16:30 +0000
Module Name: src
Committed By: kre
Date: Thu Sep 19 13:16:30 UTC 2024
Modified Files:
src/sys/sys: signal.h
Log Message:
PR lib/58674
bsd_signal should only be visible with _NETBSD_SOURCE - it isn't any kind of
standard function (despite also existing in other systems).
This change inspired by the PR, but doesn't fix it in any way, the tools
config script for gmake doesn't care if the function is visible in any
header, merely if present in libc.
To generate a diff of this commit:
cvs rdiff -u -r1.76 -r1.77 src/sys/sys/signal.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/sys/sys
Date: Thu, 19 Sep 2024 14:41:05 +0000
Module Name: src
Committed By: kre
Date: Thu Sep 19 14:41:05 UTC 2024
Modified Files:
src/sys/sys: signal.h
Log Message:
PR lib/58674 (not really so much any more)
Correct previous.
bsd_signal should only be visible with _NETBSD_SOURCE - it isn't any kind of
standard function (despite also existing in other systems).
Turns out that it used to be an XSI function, back in the dark ages
('twas removed in POSIX issue 7, back in 2008, after being marked
obsolete in issue 6 (2001)).
So, make it visible to any applications that request a suitable
X/Open version (and of course, for _NETBSD_SOURCE).
Still no effect on the issue for the PR.
To generate a diff of this commit:
cvs rdiff -u -r1.77 -r1.78 src/sys/sys/signal.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/external/gpl2/gmake/dist
Date: Thu, 19 Sep 2024 22:01:07 +0000
Module Name: src
Committed By: kre
Date: Thu Sep 19 22:01:07 UTC 2024
Modified Files:
src/external/gpl2/gmake/dist: main.c
Log Message:
PR lib/58674
Hopefully allow the tools gmake to build (everywhere).
Don't use the system bsd_signal() function, even if one is
defined, use a locally defined one instead. Note that it
cannot be declared static (which the code would do) as it
is possible that system header files might define the function,
if it exists on the host system, and that prototype would not
(cannot) be static.
This is a horrible hack, feel free to do something better.
Note: this version of gmake is (currently anyway) used only
as part of the tools used for building NetBSD - apart from that
it is used for nothing.
To generate a diff of this commit:
cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl2/gmake/dist/main.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: kre@NetBSD.org
State-Changed-When: Thu, 19 Sep 2024 22:09:04 +0000
State-Changed-Why:
I have made a change to gmake/main.c in HEAD that might enable it to
work on your system (without additional hacks required).
This is a horrible hack - Christos (mostly, some leg work from me)
is working on a better solution, which might eventually replace the
current one.
Let us know if this works for you.
State-Changed-From-To: feedback->open
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Fri, 20 Sep 2024 21:15:55 +0000
State-Changed-Why:
All issues resolved. Leaving open pending other considerations (maybe pullups).
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/58674 (HEAD fails to build tools on recent Linux (Fedora
40))
Date: Fri, 20 Sep 2024 17:11:54 -0400
On Thu, 2024-09-19 at 22:09 +0000, kre@NetBSD.org wrote:
> Synopsis: HEAD fails to build tools on recent Linux (Fedora 40)
>=20
> State-Changed-From-To: open->feedback
> State-Changed-By: kre@NetBSD.org
> State-Changed-When: Thu, 19 Sep 2024 22:09:04 +0000
> State-Changed-Why:
> I have made a change to gmake/main.c in HEAD that might enable it to
> work on your system (without additional hacks required).
>=20
> This is a horrible hack - Christos (mostly, some leg work from me)
> is working on a better solution, which might eventually replace the
> current one.
>=20
> Let us know if this works for you.
Confirming this change fixed the gmake build for me, thanks. (I removed
all tools and rebuilt from the beginning to confirm no issues now.)
Thanks,
Dave
State-Changed-From-To: open->needs-pullups
State-Changed-By: rin@NetBSD.org
State-Changed-When: Fri, 20 Sep 2024 21:24:13 +0000
State-Changed-Why:
Nice to have these fixes in 10.1 and 9.5.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/58674 (HEAD fails to build tools on recent Linux (Fedora 40))
Date: Sat, 21 Sep 2024 05:20:15 +0700
Date: Fri, 20 Sep 2024 21:24:13 +0000 (UTC)
From: rin@NetBSD.org
Message-ID: <20240920212413.A7CF91A923E@mollari.NetBSD.org>
| Nice to have these fixes in 10.1 and 9.5.
I will wait a little, then send pull-ups for whatever is appropriate.
I prefer to give changes a week or so (at least) to marinate, before
pushing them into stable releases.
kre
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@netbsd.org, lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc:
Subject: Re: lib/58674 (HEAD fails to build tools on recent Linux (Fedora 40))
Date: Sat, 21 Sep 2024 07:36:18 +0900
On 2024/09/21 7:25, Robert Elz via gnats wrote:
> I will wait a little, then send pull-ups for whatever is appropriate.
> I prefer to give changes a week or so (at least) to marinate, before
> pushing them into stable releases.
Understood! Thanks for your consideration.
rin
Responsible-Changed-From-To: lib-bug-people->kre
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Mon, 14 Oct 2024 00:20:49 +0000
Responsible-Changed-Why:
Can I trouble you to submit the pullups for this, if you haven't already?
From: kre@NetBSD.ORG
To: gnats-bugs@NetBSD.ORG
Cc: david@gutteridge.ca
Subject: Re: lib/58674: HEAD fails to build tools on recent Linux (Fedora 40)
Date: Mon, 14 Oct 2024 21:25:15 +0700 (+07)
[pullup-10 #978] requested (I will look into one for -9 later)
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: [netbsd-10] src
Date: Mon, 14 Oct 2024 17:44:58 +0000
Module Name: src
Committed By: martin
Date: Mon Oct 14 17:44:58 UTC 2024
Modified Files:
src/bin/date [netbsd-10]: date.c
src/external/gpl2/gmake/dist [netbsd-10]: main.c
src/sys/sys [netbsd-10]: signal.h
src/usr.bin/sed [netbsd-10]: process.c
Log Message:
Pull up following revision(s) (requested by kre in ticket #978):
bin/date/date.c (apply patch)
usr.bin/sed/process.c: revision 1.54
sys/sys/signal.h: revision 1.77
sys/sys/signal.h: revision 1.78
external/gpl2/gmake/dist/main.c: revision 1.2
PR lib/58674
When building the tools version of sed, treat all wide characters
as if they occupy just one column for the purposes of sed's 'l'
command (which it is very unlikely to be used from the tools sed).
wdwidth() is another XSI function, not necessarily available everywhere.
PR lib/58674
bsd_signal should only be visible with _NETBSD_SOURCE - it isn't any kind =
of
standard function (despite also existing in other systems).
This change inspired by the PR, but doesn't fix it in any way, the tools
config script for gmake doesn't care if the function is visible in any
header, merely if present in libc.
PR lib/58674 (not really so much any more)
Correct previous.
bsd_signal should only be visible with _NETBSD_SOURCE - it isn't any kind =
of
standard function (despite also existing in other systems).
Turns out that it used to be an XSI function, back in the dark ages
('twas removed in POSIX issue 7, back in 2008, after being marked
obsolete in issue 6 (2001)).
So, make it visible to any applications that request a suitable
X/Open version (and of course, for _NETBSD_SOURCE).
Still no effect on the issue for the PR.
PR lib/58674
Hopefully allow the tools gmake to build (everywhere).
Don't use the system bsd_signal() function, even if one is
defined, use a locally defined one instead. Note that it
cannot be declared static (which the code would do) as it
is possible that system header files might define the function,
if it exists on the host system, and that prototype would not
(cannot) be static.
This is a horrible hack, feel free to do something better.
Note: this version of gmake is (currently anyway) used only
as part of the tools used for building NetBSD - apart from that
it is used for nothing.
To generate a diff of this commit:
cvs rdiff -u -r1.63.2.1 -r1.63.2.2 src/bin/date/date.c
cvs rdiff -u -r1.1.1.1 -r1.1.1.1.26.1 src/external/gpl2/gmake/dist/main.c
cvs rdiff -u -r1.75.4.1 -r1.75.4.2 src/sys/sys/signal.h
cvs rdiff -u -r1.53 -r1.53.6.1 src/usr.bin/sed/process.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: kre@NetBSD.org
State-Changed-When: Tue, 15 Oct 2024 16:33:04 +0000
State-Changed-Why:
[pullup-9 #1914] (pullup to -10 has already been completed).
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: [netbsd-9] src
Date: Tue, 15 Oct 2024 18:34:41 +0000
Module Name: src
Committed By: martin
Date: Tue Oct 15 18:34:41 UTC 2024
Modified Files:
src/bin/date [netbsd-9]: date.c
src/external/gpl2/gmake/dist [netbsd-9]: main.c
src/sys/sys [netbsd-9]: signal.h
src/usr.bin/sed [netbsd-9]: process.c
Log Message:
Pull up following revision(s) (requested by kre in ticket #1914):
bin/date/date.c (apply patch)
usr.bin/sed/process.c: revision 1.54
sys/sys/signal.h: revision 1.77
sys/sys/signal.h: revision 1.78
external/gpl2/gmake/dist/main.c: revision 1.2
PR lib/58674
When building the tools version of sed, treat all wide characters
as if they occupy just one column for the purposes of sed's 'l'
command (which it is very unlikely to be used from the tools sed).
wdwidth() is another XSI function, not necessarily available everywhere.
PR lib/58674
bsd_signal should only be visible with _NETBSD_SOURCE - it isn't any kind of
standard function (despite also existing in other systems).
This change inspired by the PR, but doesn't fix it in any way, the tools
config script for gmake doesn't care if the function is visible in any
header, merely if present in libc.
PR lib/58674 (not really so much any more)
Correct previous.
bsd_signal should only be visible with _NETBSD_SOURCE - it isn't any kind of
standard function (despite also existing in other systems).
Turns out that it used to be an XSI function, back in the dark ages
('twas removed in POSIX issue 7, back in 2008, after being marked
obsolete in issue 6 (2001)).
So, make it visible to any applications that request a suitable
X/Open version (and of course, for _NETBSD_SOURCE).
Still no effect on the issue for the PR.
PR lib/58674
Hopefully allow the tools gmake to build (everywhere).
Don't use the system bsd_signal() function, even if one is
defined, use a locally defined one instead. Note that it
cannot be declared static (which the code would do) as it
is possible that system header files might define the function,
if it exists on the host system, and that prototype would not
(cannot) be static.
This is a horrible hack, feel free to do something better.
Note: this version of gmake is (currently anyway) used only
as part of the tools used for building NetBSD - apart from that
it is used for nothing.
To generate a diff of this commit:
cvs rdiff -u -r1.61.18.1 -r1.61.18.2 src/bin/date/date.c
cvs rdiff -u -r1.1.1.1 -r1.1.1.1.18.1 src/external/gpl2/gmake/dist/main.c
cvs rdiff -u -r1.72 -r1.72.16.1 src/sys/sys/signal.h
cvs rdiff -u -r1.52 -r1.52.18.1 src/usr.bin/sed/process.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->open
State-Changed-By: kre@NetBSD.org
State-Changed-When: Wed, 16 Oct 2024 18:27:55 +0000
State-Changed-Why:
Pullups (so far) complete. but it appears there remains more to do.
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/58674 (HEAD fails to build tools on recent Linux (Fedora 40))
Date: Wed, 16 Oct 2024 21:08:29 -0400
On 2024-10-16 14:27, kre@NetBSD.org wrote:
> Pullups (so far) complete. but it appears there remains more to do.
My tools build testing was for an amd64 target, so it didn't cover
mkubootimage(1). (It unfortunately didn't occur to me to try other
port combinations.)
I see on Solaris-related OSes sys/endian.h doesn't exist, so there
may be several non-portable assumptions with mkubootimage(1).
Dave
From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/usr.bin/mkubootimage
Date: Tue, 29 Oct 2024 02:54:38 +0000
Module Name: src
Committed By: gutteridge
Date: Tue Oct 29 02:54:38 UTC 2024
Modified Files:
src/usr.bin/mkubootimage: mkubootimage.c
Log Message:
mkubootimage.c: consistently use endian.h origin functions
Since this already uses bswap32(3), le64toh(3), etc., switch to also
use htobe32(3) and be32toh(3) instead of htonl(3) and ntohl(3). This
seems the best way to fix build breakages under recent Linux distros
where GCC objects to missing prototypes (since otherwise we'd need to
include arpa/inet.h, which wasn't declared). Another issue related to
PR lib/58674.
Confirmed this fixes builds on Fedora 40 (since all these functions are
provided by NetBSD compat). No changes noted to resulting installation
images generated for armv7hf on a NetBSD build.
To generate a diff of this commit:
cvs rdiff -u -r1.33 -r1.34 src/usr.bin/mkubootimage/mkubootimage.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/sys/arch/hppa/stand/mkboot
Date: Thu, 31 Oct 2024 01:21:12 +0000
Module Name: src
Committed By: gutteridge
Date: Thu Oct 31 01:21:12 UTC 2024
Modified Files:
src/sys/arch/hppa/stand/mkboot: mkboot.c
Log Message:
mkboot.c: ensure all functions are declared
Addresses build failure issue on current Linux distros that have a GCC
with implicit-function-declaration baked in as an error. Use be32toh(3)
instead of ntohl(3), seems to make more sense stylistically. Build
tested on Fedora 40.
Issue reported by Jan-Benedict Glaw. Also relevant to PR lib/58674.
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/sys/arch/hppa/stand/mkboot/mkboot.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/usr.bin/elf2aout
Date: Fri, 1 Nov 2024 00:35:53 +0000
Module Name: src
Committed By: gutteridge
Date: Fri Nov 1 00:35:53 UTC 2024
Modified Files:
src/usr.bin/elf2aout: elf2aout.c
Log Message:
elf2aout.c: switch to use htobe32(3)
As discussed on tech-toolchain. Tested with virt68k tools build on
Fedora 40. (Relevant to PR lib/58674.)
To generate a diff of this commit:
cvs rdiff -u -r1.24 -r1.25 src/usr.bin/elf2aout/elf2aout.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David H. Gutteridge" <gutteridge@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: src/sys/arch/powerpc/stand/mkbootimage
Date: Sun, 3 Nov 2024 03:11:25 +0000
Module Name: src
Committed By: gutteridge
Date: Sun Nov 3 03:11:24 UTC 2024
Modified Files:
src/sys/arch/powerpc/stand/mkbootimage: mkbootimage.c
Log Message:
mkbootimage.c: consistently use sa_htobe32(2)
There were 38 calls to sa_htobe32(2) and two to htonl(3), mixed even
within the same function, with arpa/inet.h not included. (It's unclear
why this varied, as the original version of this file first checked in
included this discrepancy.)
Addresses build failure issue on current Linux distros that have a GCC
with implicit-function-declaration baked in as an error. Build tested
on Fedora 40.
Issue reported by Jan-Benedict Glaw. Also relevant to PR lib/58674.
To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 \
src/sys/arch/powerpc/stand/mkbootimage/mkbootimage.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->pending-pullups
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Wed, 11 Dec 2024 16:20:00 +0000
State-Changed-Why:
Further pullups pending for netbsd-10: #1019 & #1023.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: [netbsd-10] src
Date: Sun, 15 Dec 2024 12:57:33 +0000
Module Name: src
Committed By: martin
Date: Sun Dec 15 12:57:33 UTC 2024
Modified Files:
src/sys/arch/hppa/stand/mkboot [netbsd-10]: mkboot.c
src/sys/arch/powerpc/stand/mkbootimage [netbsd-10]: mkbootimage.c
src/usr.bin/elf2aout [netbsd-10]: elf2aout.c
Log Message:
Pull up following revision(s) (requested by gutteridge in ticket #1019):
sys/arch/hppa/stand/mkboot/mkboot.c: revision 1.5
sys/arch/powerpc/stand/mkbootimage/mkbootimage.c: revision 1.21
usr.bin/elf2aout/elf2aout.c: revision 1.25
mkboot.c: ensure all functions are declared
Addresses build failure issue on current Linux distros that have a GCC
with implicit-function-declaration baked in as an error. Use be32toh(3)
instead of ntohl(3), seems to make more sense stylistically. Build
tested on Fedora 40.
Issue reported by Jan-Benedict Glaw. Also relevant to PR lib/58674.
elf2aout.c: switch to use htobe32(3)
As discussed on tech-toolchain. Tested with virt68k tools build on
Fedora 40. (Relevant to PR lib/58674.)
mkbootimage.c: consistently use sa_htobe32(2)
There were 38 calls to sa_htobe32(2) and two to htonl(3), mixed even
within the same function, with arpa/inet.h not included. (It's unclear
why this varied, as the original version of this file first checked in
included this discrepancy.)
Addresses build failure issue on current Linux distros that have a GCC
with implicit-function-declaration baked in as an error. Build tested
on Fedora 40.
Issue reported by Jan-Benedict Glaw. Also relevant to PR lib/58674.
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.2.48.1 src/sys/arch/hppa/stand/mkboot/mkboot.c
cvs rdiff -u -r1.19 -r1.19.48.1 \
src/sys/arch/powerpc/stand/mkbootimage/mkbootimage.c
cvs rdiff -u -r1.23.10.1 -r1.23.10.2 src/usr.bin/elf2aout/elf2aout.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/58674 CVS commit: [netbsd-10] src/usr.bin/mkubootimage
Date: Sun, 15 Dec 2024 14:38:14 +0000
Module Name: src
Committed By: martin
Date: Sun Dec 15 14:38:14 UTC 2024
Modified Files:
src/usr.bin/mkubootimage [netbsd-10]: crc32.c mkubootimage.1
mkubootimage.c
Added Files:
src/usr.bin/mkubootimage [netbsd-10]: crc32.h
Log Message:
Pull up following revision(s) (requested by gutteridge in ticket #1023):
usr.bin/mkubootimage/mkubootimage.1: revision 1.15
usr.bin/mkubootimage/crc32.c: revision 1.5
usr.bin/mkubootimage/mkubootimage.c: revision 1.31
usr.bin/mkubootimage/mkubootimage.c: revision 1.34
usr.bin/mkubootimage/crc32.h: revision 1.1
PR/57914: Jan-Benedict Glaw: Set reproducible timestamp
Cleanup lint.
mkubootimage.c: consistently use endian.h origin functions
Since this already uses bswap32(3), le64toh(3), etc., switch to also
use htobe32(3) and be32toh(3) instead of htonl(3) and ntohl(3). This
seems the best way to fix build breakages under recent Linux distros
where GCC objects to missing prototypes (since otherwise we'd need to
include arpa/inet.h, which wasn't declared). Another issue related to
PR lib/58674.
Confirmed this fixes builds on Fedora 40 (since all these functions are
provided by NetBSD compat). No changes noted to resulting installation
images generated for armv7hf on a NetBSD build.
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.4.40.1 src/usr.bin/mkubootimage/crc32.c
cvs rdiff -u -r0 -r1.2.2.2 src/usr.bin/mkubootimage/crc32.h
cvs rdiff -u -r1.14 -r1.14.8.1 src/usr.bin/mkubootimage/mkubootimage.1
cvs rdiff -u -r1.30 -r1.30.8.1 src/usr.bin/mkubootimage/mkubootimage.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: gutteridge@NetBSD.org
State-Changed-When: Sun, 15 Dec 2024 23:04:11 +0000
State-Changed-Why:
Pullups now completed, closing.
>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