Date: Thu, 28 Nov 2013 08:14:17 +0900 (JST) From: Gerald Pfeifer <gerald@pfeifer.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: ports@FreeBSD.org, "Mikhail T." <mi+thun@aldan.algebra.com> Subject: Re: Why can't lang/gcc4X compilers build kernel modules? Message-ID: <alpine.LNX.2.00.1311280813470.1711@tuna.site> In-Reply-To: <89AD564E-A6BA-4EEC-B3D0-04C18AF5F1D8@FreeBSD.org> References: <518D2773.40504@aldan.algebra.com> <89AD564E-A6BA-4EEC-B3D0-04C18AF5F1D8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 May 2013, Dimitry Andric wrote: > On May 10, 2013, at 18:59, Mikhail T. <mi+thun@aldan.algebra.com> wrote: >> Would it be too much work to extend the port-installed compilers the >> same way gcc-4.2.1 in the base is extended? May be not for gcc4[89], >> which are complete rewrites, but for 4.[4-7]? If not too difficult, >> should it be done? > > In my opinion, this is a fruitless direction. Neither upstream gcc, nor > upstream clang will ever accept an option called "-fformat-extensions", > which enables FreeBSD kernel-specific format extensions (which might > also change in the future, so you do not really gain anything). > > I think the best solution is to get rid of all non-standard printf > format specifiers in the kernel, and use custom formatters for our > specialized needs. For replacing the %b specifier, for example, we > could use NetBSD's snprintb() (see > <http://netbsd.gw.com/cgi-bin/man-cgi?snprintb+3+NetBSD-current>). > > Getting rid of non-standard extensions in general is really the way to > go. This would enable compiling with any standards-compliant compiler, > even commercial ones. Amen. Gerald
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1311280813470.1711>