Re: Error building kernel in current

From: Gary Jennejohn <garyj_at_gmx.de>
Date: Sat, 03 Jun 2023 08:18:43 UTC
On Fri, 02 Jun 2023 19:57:40 +0100
"Alexander Chernikov" <melifaro@FreeBSD.org> wrote:

> On Fri, 2 Jun 2023, at 4:30 PM, Gary Jennejohn wrote:
> > On Fri, 2 Jun 2023 09:59:40 +0000
> > Gary Jennejohn <garyj@gmx.de> wrote:
> >
> > > On Fri, 2 Jun 2023 09:56:44 +0000
> > > Gary Jennejohn <garyj@gmx.de> wrote:
> > >
> > > > Error building kernel in current:
> > > >
> > > > --------------------------------------------------------------
> > > > >>> stage 3.1: building everything
> > > > --------------------------------------------------------------
> > > > /usr/src/sys/netlink/route/iface.c:1315:22: error: use of undeclared
> > > > identifier 'if_flags'
> > > >         if (error == 0 && !(if_flags & IFF_UP) && (if_getflags(ifp) & IFF_UP))
> > > >                             ^
> > > > 1 error generated.
> > > > --- iface.o ---
> > > > *** [iface.o] Error code 1
> Sorry for the breakage, I?ll fix it in a couple of hours.
> > > >
> > > > My source tree was updated just a few minutes ago and I didn't see any
> > > > recent changes to iface.c.
> > > >
> > > > I have WITHOUT_NETLINK_SUPPORT= in my src.conf.
> > > >
> > >
> > > Ah, my error.  The failure occurs while building the kernel, so I fixed
> > > Subject accordingly.
> > >
> >
> > OK, this is another INET6 error.  I don't have INET6 enabled.
> >
> > At line 1280 we have:
> > #ifdef INET6
> > int if_flags = if_getflags(ifp);
> > #endif
> >
> > and if_flags is used at line 1315 without checking whether INET6 is
> > defined.
> >
> > if_flags seems to be totally redundant, since the code at line 1315 will
> > invoke if_getflags(ifp) if !(if_flags & IFF_UP) is true.
> >
> I wish it was true.  The case here is that interface flags can change
> after adding the address, as many interface drivers silently bring the
> interface up upon the first address addition.  Please see
> https://cgit.freebsd.org/src/commit/sys/netinet6?id=a77facd27368f618520d25391cfce11149879a41
> description for a more detailed explanation.


I suspected that may have been the reason, but I wasn't sure.  Thanks for
the link.

--
Gary Jennejohn