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:

NetBSD Home
NetBSD PR Database Search

(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.