Date: Mon, 27 Feb 2023 20:44:31 -0700 From: Warner Losh <imp@bsdimp.com> To: Dimitry Andric <dim@freebsd.org> Cc: Paul Mather <paul@gromit.dlib.vt.edu>, FreeBSD User <freebsd@walstatt-de.de>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C Message-ID: <CANCZdfpq=QQpeLXKPHKRjNXRhv9xAD-SogP88T0z7jg46yXtrw@mail.gmail.com> In-Reply-To: <1F3F20A1-C2BC-4A33-ABFD-D20F4ADB67E8@FreeBSD.org> References: <20230227192011.08f7aa8e@thor.intern.walstatt.dynvpn.de> <E2AFBCE9-4467-4E75-B7E4-4C6E0B03C0AA@FreeBSD.org> <720721A7-B1ED-405B-98EB-04A3AFCA7FD5@gromit.dlib.vt.edu> <1F3F20A1-C2BC-4A33-ABFD-D20F4ADB67E8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000086080005f5ba6afb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2023 at 3:46=E2=80=AFPM Dimitry Andric <dim@freebsd.org> wr= ote: > On 27 Feb 2023, at 22:23, Paul Mather <paul@gromit.dlib.vt.edu> wrote: > > > > On Feb 27, 2023, at 2:57 PM, Dimitry Andric <dim@FreeBSD.org> wrote: > > > >> On 27 Feb 2023, at 19:19, FreeBSD User <freebsd@walstatt-de.de> wrote: > >>> > >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > main-n261147-b8bb73ab724b: Sun Feb 26 > >>> 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git > stable/13). > >>> > >>> Building an appliance based on 13-STABLE sources, a customized kernel > via nanoBSD, since a > >>> couple of weeks for now building the sources fails in kernel sources: > >>> > >>> [...] > >>> --- modules-all --- > >>> --- all_subdir_an --- > >>> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev/an/if_an_p= ci.c:143:1: > error: a > >>> function definition without a prototype is deprecated in all versions > of C and is not > >>> supported in C2x [-Werror,-Wdeprecated-non-prototype] > >>> [..] > >>> > >>> Disabling all wireless options in the kernel config starts dropping > errors of a similar kind > >>> on other kernel places. > >>> > >>> Compiling on FBSD 13-STABLE seems to be all right. > >>> > >>> Can this be fixed. please? What causes the error and how can this be > resolved if the subtree > >>> of FreeBSD's sources is a submodule? > >> > >> Not sure what you mean with "subtree is a submodule", but this is like= ly > >> caused by skipping the cross-tools stage somehow. Do you have any > >> specific make.conf or src.conf settings for that? > > > > > > I got bitten by this recently. In my case, it was Poudriere (running o= n > 14-CURRENT) trying to build a 13-STABLE jail. The Poudriere jail's > "src.conf" was taken from the actual system for which Poudriere builds > packages. It had (amongst others) these two options: > > > > WITH_SYSTEM_COMPILER=3Dyes > > WITHOUT_CROSS_COMPILER=3Dyes > > > > > > When I commented these out in the jail-src.conf Poudriere file the jail > built correctly. > > > > I figure the system built fine because its system compiler is LLVM > 14.x. The Poudriere system compiler is LLVM 15.x, which has the breaking > change wrt. old-style prototypes. > > Yes, that is what I suspected in Oliver's case: if you skip the > cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by > setting WITH_SYSTEM_COMPILER, you are bound to run into compilation > errors that have been fixed in 14-CURRENT, but not yet MFC'd. > > The safest solution is to let cross-tools do its thing, which will check > the host compiler, and automatically build an appropriate version of the > compiler and linker for the stable branch, if required. > > That said, I will be merging clang 15.0.7 and a bunch of other things > that should solve all these errors to stable/13 at some point, but not > before the 13.2-RELEASE is out. This is to avoid making life more > difficult for our release engineering team. > In the meantime, I think you can disable -Werror with MK_WERROR=3Dno in one of the nanobsd config file. The warnings are significantly less relevant for stable/xx because they are not likely to inspire people to fix them like they would on main. And to fix these, you'd need to merge the fixes from head, or at least the neutering of large classes of errors like we had (still have?) in main.... Warner > -Dimitry > > --00000000000086080005f5ba6afb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 27, 2023 at 3:46=E2=80=AF= PM Dimitry Andric <<a href=3D"mailto:dim@freebsd.org">dim@freebsd.org</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On = 27 Feb 2023, at 22:23, Paul Mather <<a href=3D"mailto:paul@gromit.dlib.v= t.edu" target=3D"_blank">paul@gromit.dlib.vt.edu</a>> wrote:<br> > <br> > On Feb 27, 2023, at 2:57 PM, Dimitry Andric <dim@FreeBSD.org> wr= ote:<br> > <br> >> On 27 Feb 2023, at 19:19, FreeBSD User <<a href=3D"mailto:freeb= sd@walstatt-de.de" target=3D"_blank">freebsd@walstatt-de.de</a>> wrote:<= br> >>> <br> >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 main-= n261147-b8bb73ab724b: Sun Feb 26<br> >>> 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git s= table/13).<br> >>> <br> >>> Building an appliance based on 13-STABLE sources, a customized= kernel via nanoBSD, since a<br> >>> couple of weeks for now building the sources fails in kernel s= ources:<br> >>> <br> >>> [...]<br> >>> --- modules-all ---<br> >>> --- all_subdir_an ---<br> >>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/sys/dev= /an/if_an_pci.c:143:1: error: a<br> >>> function definition without a prototype is deprecated in all v= ersions of C and is not<br> >>> supported in C2x [-Werror,-Wdeprecated-non-prototype]<br> >>> [..]<br> >>> <br> >>> Disabling all wireless options in the kernel config starts dro= pping errors of a similar kind<br> >>> on other kernel places.<br> >>> <br> >>> Compiling on FBSD 13-STABLE seems to be all right.<br> >>> <br> >>> Can this be fixed. please? What causes the error and how can t= his be resolved if the subtree<br> >>> of FreeBSD's sources is a submodule?<br> >> <br> >> Not sure what you mean with "subtree is a submodule", bu= t this is likely<br> >> caused by skipping the cross-tools stage somehow. Do you have any<= br> >> specific make.conf or src.conf settings for that?<br> > <br> > <br> > I got bitten by this recently.=C2=A0 In my case, it was Poudriere (run= ning on 14-CURRENT) trying to build a 13-STABLE jail.=C2=A0 The Poudriere j= ail's "src.conf" was taken from the actual system for which P= oudriere builds packages.=C2=A0 It had (amongst others) these two options:<= br> > <br> > WITH_SYSTEM_COMPILER=3Dyes<br> > WITHOUT_CROSS_COMPILER=3Dyes<br> > <br> > <br> > When I commented these out in the jail-src.conf Poudriere file the jai= l built correctly.<br> > <br> > I figure the system built fine because its system compiler is LLVM 14.= x.=C2=A0 The Poudriere system compiler is LLVM 15.x, which has the breaking= change wrt. old-style prototypes.<br> <br> Yes, that is what I suspected in Oliver's case: if you skip the<br> cross-tools stage in a buildworld of stable/13 on a 14-CURRENT host, by<br> setting WITH_SYSTEM_COMPILER, you are bound to run into compilation<br> errors that have been fixed in 14-CURRENT, but not yet MFC'd.<br> <br> The safest solution is to let cross-tools do its thing, which will check<br= > the host compiler, and automatically build an appropriate version of the<br= > compiler and linker for the stable branch, if required.<br> <br> That said, I will be merging clang 15.0.7 and a bunch of other things<br> that should solve all these errors to stable/13 at some point, but not<br> before the 13.2-RELEASE is out. This is to avoid making life more<br> difficult for our release engineering team.<br></blockquote><div><br></div>= <div>In the meantime, I think you can disable -Werror with MK_WERROR=3Dno i= n one</div><div>of the nanobsd config file. The warnings are significantly = less relevant for stable/xx</div><div>because they are not likely to inspir= e people to fix them like they would on main.</div><div><br></div><div>And = to fix these, you'd need to merge the fixes from head, or at least the = neutering</div><div>of large classes of errors like we had (still have?) in= main....<br></div><div><br></div><div>Warner<br></div><div>=C2=A0</div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"> -Dimitry<br> <br> </blockquote></div></div> --00000000000086080005f5ba6afb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpq=QQpeLXKPHKRjNXRhv9xAD-SogP88T0z7jg46yXtrw>