Skip site navigation (1)Skip section navigation (2)
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>