Re: Errors building netbsd-8 on sparc64

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

On Tue, 10 Oct 2017 00:51:39 -0400
Michael <macallan%netbsd.org@localhost> wrote:

> Hello,
> 
> On Mon, 9 Oct 2017 22:38:32 +0100
> Sad Clouds <cryintothebluesky%googlemail.com@localhost> wrote:
> 
> > On Mon, 9 Oct 2017 09:25:18 +0200
> > Martin Husemann <martin%duskware.de@localhost> wrote:
> > 
> > > On Mon, Oct 09, 2017 at 09:08:17AM +0200, Martin Husemann wrote:  
> > > > On Mon, Oct 09, 2017 at 06:43:43AM +0100, Sad Clouds wrote:  
> > > > > Hi commenting out these two in mk.conf resulted in a
> > > > > successful build
> > > > > 
> > > > > COPTS+=-pipe
> > > > > CPUFLAGS+=-mcpu=ultrasparc
> > > > > 
> > > > > I think it's the CPUFLAGS option that causes issues. This
> > > > > looks like a NetBSD bug, as I mentioned previously, it used
> > > > > to work for years, until now.  
> > > > 
> > > > It has to be: the default for -mcpu is ultrasparc anyway, so
> > > > this is a no-op at the compiler level.  
> > > 
> > > I can not reproduce it, but I used a slightly different variation:
> > > 
> > > .if ! defined(_ETC_MK_PIPE_DONE)
> > > _ETC_MK_PIPE_DONE=1
> > > CFLAGS += -pipe
> > > .endif
> > > 
> > > .if ${MACHINE} == "sparc"
> > > CFLAGS+= -mcpu=v8 -mtune=supersparc
> > > .elif ${MACHINE} == "sparc64"
> > > CPUFLAGS+=-mcpu=ultrasparc
> > > .endif
> > > 
> > > 
> > > Martin  
> > 
> > Hi, just tried different combinations and strangely, setting
> > 
> > COPTS+=-pipe
> > 
> > causes the failure, nothing to do with -mcpu flags.
> 
> Hmm, I've had -O2 -mcpu=ultrasparc -pipe in CFLAGS since ~forever,
> never seen any problems with it.
> 
> have fun
> Michael

Hi, I'm not setting CFLAGS, instead I'm setting COPTS and CPUFLAGS,
because manpage for mk.conf specifically says that you shouldn't set
CFLAGS. Not sure why.

I remember having similar issues building earmv7hf so I did a search on
NetBSD mailing lists and it showed up older email where COPTS was
causing issues with -O2 flag

https://mail-index.netbsd.org/port-arm/2016/07/10/msg003872.html

Looks like this could be something similar, but on sparc64. I think
NetBSD Makefiles need fixing, but I don't know how/where.