NetBSD Problem Report #54581
From buhrow@lothlorien.nfbcal.org Fri Sep 27 19:53:18 2019
Return-Path: <buhrow@lothlorien.nfbcal.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-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 50F567A189
for <gnats-bugs@www.NetBSD.org>; Fri, 27 Sep 2019 19:53:18 +0000 (UTC)
Message-Id: <201909271953.x8RJrGtl021536@lothlorien.nfbcal.org>
Date: Fri, 27 Sep 2019 12:53:16 -0700 (PDT)
From: buhrow@nfbcal.org
Reply-To: buhrow@nfbcal.org
To: gnats-bugs@www.NetBSD.org
Subject: Issues building NetBSD-9 under NetBSD-5.2
X-Send-Pr-Version: 3.95
>Number: 54581
>Category: misc
>Synopsis: Various issues trying to build release NetBSD-9 under NetBSD-5.2
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: misc-bug-people
>State: feedback
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Sep 27 19:55:00 +0000 2019
>Closed-Date:
>Last-Modified: Sat Jun 10 18:52:07 +0000 2023
>Originator: Brian Buhrow
>Release: NetBSD 5.2_STABLE
>Organization:
NFB of California
>Environment:
System: NetBSD lothlorien.nfbcal.org 5.2_STABLE NetBSD 5.2_STABLE (RBL) #0: Thu Mar 27 10:15:56 PDT 2014 buhrow@lothlorien.nfbcal.org:/usr/src/sys/arch/i386/compile/RBL i386
Architecture: i386
Machine: i386
>Description:
I'm trying to build release, using build.sh, NetBSD-9 hosted on a
NetBSD-5.2 system. I'm running into various build errors. I'm not sure if
I should file a bug for each error, or just document them here. I'm also
creating patches which can be committed to head to correct these issues.
I'm assuming, I think correctly, that if I'm having these issues with
NetBSD-9, -current will encounter the same issues. NetBSD-8 builds fine
under NetBSD-5.2.
>How-To-Repeat:
Run build.sh on a NetBSD-9 source tree on a system running NetBSD-5.2.
The sample command I'm using is:
./build.sh -m amd64 -D /var/tmp/netbsd-90-64 -O /usr/local/netbsd/obj-64 -j 2 release
>Fix:
For the first issue, under NetBSD-5.2, __CTASSERT() is not defined in
/usr/include/sys/cdefs.h, as it is under NetBSD-6 and later. This causes
the ctf suite of tools not to build. The patch below corrects this problem
and allows the ctf tools to build.
Is this the proper approach to fixing these kinds of issues? If so, should
I commit these fixes once the build is working successfully?
-thanks
-Brian
Index: debug.h
===================================================================
RCS file: /cvsroot/src/external/cddl/osnet/dist/uts/common/sys/debug.h,v
retrieving revision 1.4
diff -u -r1.4 debug.h
--- debug.h 28 May 2018 21:05:07 -0000 1.4
+++ debug.h 27 Sep 2019 19:40:24 -0000
@@ -134,8 +134,14 @@
#define _CTASSERT(x, y) __CTASSERT(x, y)
#endif
#ifndef __CTASSERT
+#if (defined(__NetBSD_Version__) && __NetBSD_Version__ < 600000000)
+#define __CTASSERT(x) __CTASSERT0(x, __ctassert, __LINE__)
+#define __CTASSERT0(x, y, z) __CTASSERT1(x, y, z)
+#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 : -1]
+#else
#define __CTASSERT(x, y) \
typedef char __compile_time_assertion__ ## y [(x) ? 1 : -1]
+#endif /*__NetBSD__*/
#endif
#ifdef _KERNEL
>Release-Note:
>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sat, 28 Sep 2019 06:50:36 +1000
> Is this the proper approach to fixing these kinds of issues? If so, should
> I commit these fixes once the build is working successfully?
[ ... ]
> Index: debug.h
> ===================================================================
> RCS file: /cvsroot/src/external/cddl/osnet/dist/uts/common/sys/debug.h,v
i would expect to find patches for this in src/tools/compat
so that any code using newer netbsd features gets covered,
rather than each instance having compat code.
eg, see how _DIAGASSERT() is handled.
thanks.
.mrg.
From: Brian Buhrow <buhrow@nfbcal.org>
To: gnats-bugs@netbsd.org
Cc: buhrow@nfbcal.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Fri, 27 Sep 2019 17:27:52 -0700
hello. Here is a better patch that allows us to get past the first
build issue. What do folks think of this?
-thanks
-Brian
Index: compat_defs.h
===================================================================
RCS file: /cvsroot/src/tools/compat/compat_defs.h,v
retrieving revision 1.116
diff -u -r1.116 compat_defs.h
--- compat_defs.h 19 Jun 2019 23:33:07 -0000 1.116
+++ compat_defs.h 28 Sep 2019 00:22:42 -0000
@@ -1,4 +1,4 @@
-/* $NetBSD$ */
+/* $NetBSD: compat_defs.h,v 1.116 2019/06/19 23:33:07 kamil Exp $ */
#ifndef __NETBSD_COMPAT_DEFS_H__
#define __NETBSD_COMPAT_DEFS_H__
@@ -118,6 +118,15 @@
#if HAVE_SYS_CDEFS_H
#include <sys/cdefs.h>
+/*
+ * __CTASSERT isn't defined until NetBSD-6, allow builds that want it
+ * to build on NetBSD-5 and older.
+ */
+#if (defined(__NetBSD_Version__) && __NetBSD_Version__ < 600000000)
+#define __CTASSERT(x) __CTASSERT0(x, __ctassert, __LINE__)
+#define __CTASSERT0(x, y, z) __CTASSERT1(x, y, z)
+#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 : -1]
+#endif /*__NetBSD__*/
#endif
#if HAVE_SYS_SYSLIMITS_H
#include <sys/syslimits.h>
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sat, 28 Sep 2019 15:03:55 +0700
Date: Sat, 28 Sep 2019 00:30:01 +0000 (UTC)
From: Brian Buhrow <buhrow@nfbcal.org>
Message-ID: <20190928003001.AE24C7A23E@mollari.NetBSD.org>
| #if HAVE_SYS_CDEFS_H
| #include <sys/cdefs.h>
| +/*
| + * __CTASSERT isn't defined until NetBSD-6, allow builds that want it
| + * to build on NetBSD-5 and older.
| + */
| +#if (defined(__NetBSD_Version__) && __NetBSD_Version__ < 600000000)
That would be better done as
#ifndef __CTASSERT
| +#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 : -1]
And that one the way it is done now in HEAD, rather than that old way
(though for this purpose it doesn't matter all that much, in fact, for
the purpose, simply defining __CTASSERT() to generate nothing would do).
kre
From: Brian Buhrow <buhrow@nfbcal.org>
To: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc: buhrow@nfbcal.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sat, 28 Sep 2019 09:07:43 -0700
hello Robert. I like your suggestion, but there are two issues I ran
into using it.
1. I tried using the definitions from sys/cdefs.h in netbsd-90 sources,
but gcc 3.3.x didn't like the final usage when I tried to compile
everything up.
2. The dist sources define __CTASSERT in a different way, so I'm not sure
the test you propose will always work. Honestly, my head begins to spin
when I start tracing the include paths and the order of such includes in
the build process. I figure this way is least invasive for current builds,
though it doesn't solve the problem of cross -OS portability.
Thoughts?
-thanks
-Brian
On Sep 28, 8:05am, Robert Elz wrote:
} Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
} The following reply was made to PR misc/54581; it has been noted by GNATS.
}
} From: Robert Elz <kre@munnari.OZ.AU>
} To: gnats-bugs@netbsd.org
} Cc:
} Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
} Date: Sat, 28 Sep 2019 15:03:55 +0700
}
} Date: Sat, 28 Sep 2019 00:30:01 +0000 (UTC)
} From: Brian Buhrow <buhrow@nfbcal.org>
} Message-ID: <20190928003001.AE24C7A23E@mollari.NetBSD.org>
}
}
} | #if HAVE_SYS_CDEFS_H
} | #include <sys/cdefs.h>
} | +/*
} | + * __CTASSERT isn't defined until NetBSD-6, allow builds that want it
} | + * to build on NetBSD-5 and older.
} | + */
} | +#if (defined(__NetBSD_Version__) && __NetBSD_Version__ < 600000000)
}
} That would be better done as
} #ifndef __CTASSERT
}
} | +#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 : -1]
}
} And that one the way it is done now in HEAD, rather than that old way
} (though for this purpose it doesn't matter all that much, in fact, for
} the purpose, simply defining __CTASSERT() to generate nothing would do).
}
} kre
}
>-- End of excerpt from Robert Elz
From: Brian Buhrow <buhrow@nfbcal.org>
To: gnats-bugs@netbsd.org
Cc: buhrow@nfbcal.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sat, 28 Sep 2019 12:05:27 -0700
hello Robert Elz suggested a better patch which I've partially
implemented and tested. Here it is.
If there are no objections, I'll commit this when the process is complete.
-thanks
-Brian
Index: compat_defs.h
===================================================================
RCS file: /cvsroot/src/tools/compat/compat_defs.h,v
retrieving revision 1.116
diff -u -r1.116 compat_defs.h
--- compat_defs.h 19 Jun 2019 23:33:07 -0000 1.116
+++ compat_defs.h 28 Sep 2019 19:00:59 -0000
@@ -118,6 +118,15 @@
#if HAVE_SYS_CDEFS_H
#include <sys/cdefs.h>
+/*
+ * __CTASSERT isn't defined until NetBSD-6, allow builds that want it
+ * to build on NetBSD-5 and older.
+ */
+#ifndef __CTASSERT
+#define __CTASSERT(x) __CTASSERT0(x, __ctassert, __LINE__)
+#define __CTASSERT0(x, y, z) __CTASSERT1(x, y, z)
+#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 : -1]
+#endif /* __CTASSERT */
#endif
#if HAVE_SYS_SYSLIMITS_H
#include <sys/syslimits.h>
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sat, 28 Sep 2019 21:25:37 +0200
On 28.09.2019 21:10, Brian Buhrow wrote:
> The following reply was made to PR misc/54581; it has been noted by GNAT=
S.
>
> From: Brian Buhrow <buhrow@nfbcal.org>
> To: gnats-bugs@netbsd.org
> Cc: buhrow@nfbcal.org
> Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
> Date: Sat, 28 Sep 2019 12:05:27 -0700
>
> hello Robert Elz suggested a better patch which I've partially
> implemented and tested. Here it is.
> If there are no objections, I'll commit this when the process is comple=
te.
> -thanks
> -Brian
>
>
> Index: compat_defs.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/src/tools/compat/compat_defs.h,v
> retrieving revision 1.116
> diff -u -r1.116 compat_defs.h
> --- compat_defs.h 19 Jun 2019 23:33:07 -0000 1.116
> +++ compat_defs.h 28 Sep 2019 19:00:59 -0000
> @@ -118,6 +118,15 @@
>
> #if HAVE_SYS_CDEFS_H
> #include <sys/cdefs.h>
> +/*
> + * __CTASSERT isn't defined until NetBSD-6, allow builds that want it
> + * to build on NetBSD-5 and older.
> + */
> +#ifndef __CTASSERT
> +#define __CTASSERT(x) __CTASSERT0(x, __ctassert, __LINE__)
> +#define __CTASSERT0(x, y, z) __CTASSERT1(x, y, z)
> +#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 =
: -1]
> +#endif /* __CTASSERT */
> #endif
> #if HAVE_SYS_SYSLIMITS_H
> #include <sys/syslimits.h>
>
>
Is there any reason to pick this legacy form instead of the current one?
From: Robert Elz <kre@munnari.OZ.AU>
To: Brian Buhrow <buhrow@nfbcal.org>
Cc: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sun, 29 Sep 2019 08:12:27 +0700
Date: Sat, 28 Sep 2019 09:07:43 -0700
From: Brian Buhrow <buhrow@nfbcal.org>
Message-ID: <201909281607.x8SG7iuU018476@lothlorien.nfbcal.org>
| 1. I tried using the definitions from sys/cdefs.h in netbsd-90 sources,
| but gcc 3.3.x didn't like the final usage when I tried to compile
| everything up.
I didn't want to throw cold water on your efforts earlier, but you're
likely to suffer from more than that ... I gave up trying to build HEAD
on a -6 based system a while ago (before -9 branched I believe) as
the gcc that it contains wasn't up to the task of even building the
tools any more (or that's what I remember ... it has been a while now).
That is, I am not sure you will ever really get a satisfactory -9 or HEAD
build on a -5 system - which is a real pity, the cross build environment
should work anywhere (building anything that is needed where an old or
other system's version is not adequate).
| Thoughts?
But for __CTASSERT() it really doesn't matter what you define it to be,
just as long as it doesn't break compilation. Actually though, for
-9 the fixes needed to use the new form from HEAD may not have been pulled
up (there were a few bad __CTASSERT uses that needed fixing.) So using
the form from HEAD might not be the right thing to do after all.
It is after all just a compile time assert - its purpose is to make sure
that no-one accidentally changes the sources in a way that voilates
assumptions made elsewhere in the code. All that is needed for that to
be effective is for someone to compile with a working version of the macro.
That someone can be anyone - including the buildbots. So simply defining
the macro to ignore its args and generate nothing at all should not hurt
your build at all.
kre
From: Robert Elz <kre@munnari.OZ.AU>
To: Kamil Rytarowski <n54@gmx.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sun, 29 Sep 2019 08:16:29 +0700
Date: Sat, 28 Sep 2019 19:30:01 +0000 (UTC)
From: Kamil Rytarowski <n54@gmx.com>
Message-ID: <20190928193001.B3A9B7A245@mollari.NetBSD.org>
| Is there any reason to pick this legacy form instead of the current one?
Have all the fixes to the broken __CTASSERT uses (the ones that needed
fixing for the build to work with the current __CTASSERT()) been pullled
up to everything that it is possible to build and which contained the
broken versions?
If not, using the old one (or simply a dummy do-nothing version) when
building on an ancient system which has no __CTASSERT() at all) is going
to be needed.
kre
From: Kamil Rytarowski <n54@gmx.com>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Sun, 29 Sep 2019 03:36:37 +0200
On 29.09.2019 03:16, Robert Elz wrote:
> Date: Sat, 28 Sep 2019 19:30:01 +0000 (UTC)
> From: Kamil Rytarowski <n54@gmx.com>
> Message-ID: <20190928193001.B3A9B7A245@mollari.NetBSD.org>
>
> | Is there any reason to pick this legacy form instead of the current=
one?
>
> Have all the fixes to the broken __CTASSERT uses (the ones that needed
> fixing for the build to work with the current __CTASSERT()) been pullled
> up to everything that it is possible to build and which contained the
> broken versions?
>
Pulled up to -9? No and I do not plan to do it.
> If not, using the old one (or simply a dummy do-nothing version) when
> building on an ancient system which has no __CTASSERT() at all) is going
> to be needed.
>
> kre
>
If we want to commit new code it is better to add __CTASSERT(9) in new
style to HEAD and submit pull-request with a different version for -9.
From: Brian Buhrow <buhrow@nfbcal.org>
To: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc: kre@munnari.OZ.AU, buhrow@nfbcal.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Mon, 30 Sep 2019 13:54:15 -0700
hello Robert. In continuing to try and build netbsd-9 under
NetBSD-5.2, I've run into one of these compiler options that gcc 4.1
doesn't like and which you committed about a year ago to the tree. I
wonder if there is another way to get the same functionality, without
having to get the older version of gcc bunched up?
file you committed to:
/external/bsd/mdocml/bin/mandoc/Makefile
Commit message:
revision 1.15
date: 2018-08-16 03:59:52 +0000; author: kre; state: Exp; lines: +6 -2;
comm
itid: QkqVURZoER2OtiOA;
man_term.c needs -Wno-error=array-bounds for the exact same reason
as libmandoc/mandoc-validate.c
And as we do not have recallocarray() in libc, we need the compat
source file for the full build, as well as for tools builds.
----------------------------
From: Robert Elz <kre@munnari.OZ.AU>
To: Brian Buhrow <buhrow@nfbcal.org>
Cc: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Tue, 01 Oct 2019 12:34:03 +0700
Date: Mon, 30 Sep 2019 13:54:15 -0700
From: Brian Buhrow <buhrow@nfbcal.org>
Message-ID: <201909302054.x8UKsFdF018121@lothlorien.nfbcal.org>
| hello Robert. In continuing to try and build netbsd-9 under
| NetBSD-5.2, I've run into one of these compiler options that gcc 4.1
| doesn't like and which you committed about a year ago to the tree.
For that one I am fairly sure that I was just copying the same thing
that was done for a similar problem in another file.
But for these -Wno-xxx options, in general, they are needed whenever
the compiler implements the -Wxxx option (which the build's -Wall would
turn on) - if the compiler is old enough to not have that option, then
turning it off (which it also doesn't recognise) isn't going to work.
This kind of thing can be handled in the Makefile with a test on the
gcc version being used, if we can find out which gcc version introduced
the relevant option - and only include the -Wno-xxx for versions of gcc
that are not older than the version where the option appeared.
But I am not sure it is really worth it - that is, even with these band
aids, which could be done with no worse effects than more clutter in the
Makefiles - I am not sure you're going to be able to get a NetBSD 5 gcc to
build -9 or HEAD.
What you should do is simply remove any options like this from your source
files, when the compiler objects (comment them out with an easy pattern
to grep for later, like "#XYZ#" or something) and see if simply doing that
(as many times as is needed) is enough to get the build to complete.
If it is, do a complete recursive grep through the source tree, looking
for that pattern, so we know everywhere that would need to be changed, and
then we can see if it is worth doing this in HEAD, and requesting a pullup
to -9.
kre
From: Brian Buhrow <buhrow@nfbcal.org>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, buhrow@nfbcal.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Tue, 1 Oct 2019 10:10:02 -0700
Hello. On the success front, I've almost got NetBSD-9 building
cleanly from start to finish under netBSD-5.2. The problem I have now is
not compiler errors, but memory issues. I'm building on an i386 system
with 4GB of RAM and that seems not to be enough for concurrent compiling.
I'll report back when I have the build runing cleanly with a patch set.
The patches are minimal, which is good.
I'd like to thank everyone for the help so far in this process.
-Brian
On Oct 1, 12:34pm, Robert Elz wrote:
} Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
} Date: Mon, 30 Sep 2019 13:54:15 -0700
} From: Brian Buhrow <buhrow@nfbcal.org>
} Message-ID: <201909302054.x8UKsFdF018121@lothlorien.nfbcal.org>
}
} | hello Robert. In continuing to try and build netbsd-9 under
} | NetBSD-5.2, I've run into one of these compiler options that gcc 4.1
} | doesn't like and which you committed about a year ago to the tree.
}
} For that one I am fairly sure that I was just copying the same thing
} that was done for a similar problem in another file.
}
} But for these -Wno-xxx options, in general, they are needed whenever
} the compiler implements the -Wxxx option (which the build's -Wall would
} turn on) - if the compiler is old enough to not have that option, then
} turning it off (which it also doesn't recognise) isn't going to work.
}
} This kind of thing can be handled in the Makefile with a test on the
} gcc version being used, if we can find out which gcc version introduced
} the relevant option - and only include the -Wno-xxx for versions of gcc
} that are not older than the version where the option appeared.
}
} But I am not sure it is really worth it - that is, even with these band
} aids, which could be done with no worse effects than more clutter in the
} Makefiles - I am not sure you're going to be able to get a NetBSD 5 gcc to
} build -9 or HEAD.
}
} What you should do is simply remove any options like this from your source
} files, when the compiler objects (comment them out with an easy pattern
} to grep for later, like "#XYZ#" or something) and see if simply doing that
} (as many times as is needed) is enough to get the build to complete.
}
} If it is, do a complete recursive grep through the source tree, looking
} for that pattern, so we know everywhere that would need to be changed, and
} then we can see if it is worth doing this in HEAD, and requesting a pullup
} to -9.
}
} kre
}
>-- End of excerpt from Robert Elz
From: Brian Buhrow <buhrow@nfbcal.org>
To: gnats-bugs@netbsd.org, misc-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Cc: kre@munnari.OZ.AU, buhrow@nfbcal.org
Subject: Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2
Date: Thu, 3 Oct 2019 11:10:45 -0700
hello. I have successfully build a NetBSD-9.0_BETA releaese under
NetBSD-5.2. Patches are below. This build cannot be done on i386 systems
because it requires more than 4GB of memory. However, an 8GB system is
sufficient to complete this task.
I will next bring -current sources up to date, apply these patches and
see if I can build there.
If that is successful, I'd like to commit these fixes so this work doesn't
get lost.
One question, For the mandoc fixes, I simply commented out the offending
options. This should really be under a conditional variable that tests for
the version of gcc we're using. Can someone suggest which variable and
which syntax I can use to make the inclusion of the offending options
conditional?
-thanks
-Brian
===> build.sh command: ./build.sh -m amd64 -D /var/tmp/netbsd-90-64 -O /usr/local/netbsd/obj-64 -j 1 release
===> build.sh started: Wed Oct 2 20:49:13 PDT 2019
===> NetBSD version: 9.0_BETA
===> MACHINE: amd64
===> MACHINE_ARCH: x86_64
===> Build platform: NetBSD 5.2_STABLE amd64
Successful make release
build.sh ended: Thu Oct 3 04:37:00 PDT 2019
Index: ./external/bsd/mdocml/bin/mandoc/Makefile
===================================================================
RCS file: /cvsroot/src/external/bsd/mdocml/bin/mandoc/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- ./external/bsd/mdocml/bin/mandoc/Makefile 11 Mar 2019 17:59:28 -0000 1.18
+++ ./external/bsd/mdocml/bin/mandoc/Makefile 3 Oct 2019 17:55:31 -0000
@@ -44,6 +44,6 @@
SRCS+= ${SRCS.libmandoc} compat_strtonum.c compat_reallocarray.c
.endif
-COPTS.man_term.c+= -Wno-error=array-bounds
+#COPTS.man_term.c+= -Wno-error=array-bounds
.include <bsd.prog.mk>
Index: ./external/bsd/mdocml/lib/libmandoc/Makefile
===================================================================
RCS file: /cvsroot/src/external/bsd/mdocml/lib/libmandoc/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- ./external/bsd/mdocml/lib/libmandoc/Makefile 11 Mar 2019 00:15:38 -0000 1.12
+++ ./external/bsd/mdocml/lib/libmandoc/Makefile 3 Oct 2019 17:55:32 -0000
@@ -44,6 +44,6 @@
COPTS.mdoc_macro.c+=-O0
.endif
-COPTS.man_validate.c+=-Wno-error=array-bounds
+#COPTS.man_validate.c+=-Wno-error=array-bounds
.include <bsd.lib.mk>
Index: ./external/cddl/osnet/sys/sys/opentypes.h
===================================================================
RCS file: /cvsroot/src/external/cddl/osnet/sys/sys/opentypes.h,v
retrieving revision 1.4
diff -u -r1.4 opentypes.h
--- ./external/cddl/osnet/sys/sys/opentypes.h 6 Sep 2018 00:44:43 -0000 1.4
+++ ./external/cddl/osnet/sys/sys/opentypes.h 3 Oct 2019 17:55:32 -0000
@@ -21,10 +21,16 @@
#define __defined_ts_t
typedef struct timespec timespec_t;
#endif
+#if !HAVE_UINT_T
typedef unsigned int uint_t;
+#endif
+#ifndef HAVE_UCHAR_T
typedef unsigned char uchar_t;
+#endif
+#if !HAVE_USHORT_T
typedef unsigned short ushort_t;
typedef unsigned long ulong_t;
+#endif
typedef off_t off64_t;
typedef id_t taskid_t;
typedef id_t projid_t;
Index: ./tools/compat/compat_defs.h
===================================================================
RCS file: /cvsroot/src/tools/compat/compat_defs.h,v
retrieving revision 1.116
diff -u -r1.116 compat_defs.h
--- ./tools/compat/compat_defs.h 19 Jun 2019 23:33:07 -0000 1.116
+++ ./tools/compat/compat_defs.h 3 Oct 2019 17:55:33 -0000
@@ -65,34 +65,42 @@
#if !HAVE_U_LONG
typedef unsigned long u_long;
+#define HAVE_U_LONG 1
#endif
#if !HAVE_U_CHAR
typedef unsigned char u_char;
+#define HAVE_U_CHAR 1
#endif
#if !HAVE_U_INT
typedef unsigned int u_int;
+#define HAVE_U_INT 1
#endif
#if !HAVE_U_SHORT
typedef unsigned short u_short;
+#define HAVE_U_SHORT 1
#endif
#if !HAVE_UCHAR_T
typedef unsigned char uchar_t;
+#define HAVE_UCHAR_T 1
#endif
#if !HAVE_USHORT_T
typedef unsigned short ushort_t;
+#define HAVE_USHORT_T 1
#endif
#if !HAVE_UINT_T
typedef unsigned int uint_t;
+#define HAVE_UINT_T 1
#endif
#if !HAVE_ULONG_T
typedef unsigned long ulong_t;
+#define HAVE_ULONG_T 1
#endif
/* System headers needed for (re)definitions below. */
@@ -118,6 +126,15 @@
#if HAVE_SYS_CDEFS_H
#include <sys/cdefs.h>
+/*
+ * __CTASSERT isn't defined until NetBSD-6, allow builds that want it
+ * to build on NetBSD-5 and older.
+ */
+#ifndef __CTASSERT
+#define __CTASSERT(x) __CTASSERT0(x, __ctassert, __LINE__)
+#define __CTASSERT0(x, y, z) __CTASSERT1(x, y, z)
+#define __CTASSERT1(x, y, z) typedef char y ## z[/*CONSTCOND*/(x) ? 1 : -1]
+#endif /* __CTASSERT */
#endif
#if HAVE_SYS_SYSLIMITS_H
#include <sys/syslimits.h>
Index: ./usr.sbin/installboot/Makefile
===================================================================
RCS file: /cvsroot/src/usr.sbin/installboot/Makefile,v
retrieving revision 1.52.2.1
diff -u -r1.52.2.1 Makefile
--- ./usr.sbin/installboot/Makefile 21 Aug 2019 08:28:53 -0000 1.52.2.1
+++ ./usr.sbin/installboot/Makefile 3 Oct 2019 17:55:33 -0000
@@ -41,16 +41,16 @@
.PATH: ${FDTDIR}
CPPFLAGS+= -DSUPPORT_FDT -I${FDTDIR}
SRCS+=fdt.c fdt_ro.c fdt_strerror.c
-# XXX libfdt has some sign-comparison issues
-COPTS.fdt.c+= -Wno-error=sign-compare
-COPTS.fdt_ro.c+= -Wno-error=sign-compare
-COPTS.fdt_strerror.c+= -Wno-error=sign-compare
.endif
.if !defined(HOSTPROGNAME)
.if !empty(ARCH_FILES:C/(evbarm)/ofw/:Mofw.c)
CPPFLAGS+= -DSUPPORT_OPENFIRMWARE
+# XXX libfdt has some sign-comparison issues
+COPTS.fdt.c+= -Wno-error=sign-compare
+COPTS.fdt_ro.c+= -Wno-error=sign-compare
+COPTS.fdt_strerror.c+= -Wno-error=sign-compare
.endif
.endif
State-Changed-From-To: open->feedback
State-Changed-By: lukem@NetBSD.org
State-Changed-When: Sat, 10 Jun 2023 18:52:07 +0000
State-Changed-Why:
I don't think we need to keep this ticket open.
Supporting cross-building of our current supported
releases from platforms that are end of life / end of support
(as NetBSD 5.x is, end of support was 2015-11-11)
is not, in my opinion, feasible for the project.
Especially when the EOL host systems often have compilers
that are too old as well.
I've made some improvements to -current for how compiler
warnings can be tuned for host tools as enabled by tools/compat
that may help in the future fixing support for systems that
aren't so out of date but have older compilers. We can use that
framework to tune HOST_C*FLAGS as necessary.
>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-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.