Re: misc/54581: Issues building NetBSD-9 under NetBSD-5.2

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR misc/54581; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Brian Buhrow <buhrow%nfbcal.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, misc-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
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@localhost>
     Message-ID:  <201909281607.x8SG7iuU018476%lothlorien.nfbcal.org@localhost>
 
   | 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