Re: Errors building netbsd-8 on sparc64
Sad Clouds <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 10 Oct 2017 00:51:39 -0400 Michael <[email protected]> wrote: > Hello, > > On Mon, 9 Oct 2017 22:38:32 +0100 > Sad Clouds <[email protected]> wrote: > > > On Mon, 9 Oct 2017 09:25:18 +0200 > > Martin Husemann <[email protected]> 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.