System headers with clang?
ler at lerctr.org
Tue Oct 11 16:07:40 UTC 2011
On Tue, 11 Oct 2011, Kevin Oberman wrote:
> On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman <ler at lerctr.org> wrote:
>> On 10/11/2011 8:51 AM, Dimitry Andric wrote:
>>> On 2011-10-11 15:31, Larry Rosenman wrote:
>>>> On Tue, 11 Oct 2011, Dimitry Andric wrote:
>>>>> I've attached a fix for the lsof port, which also makes it build on
>>>>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own
>>>>> hand-rolled configuration script). Let me know if it works for you.
>>>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support
>>>> We need to get clang/system headers to allow warning free compilation
>>>> just like GCC does.
>>> The system headers compile without warning, if you use them as intended
>>> (e.g. from the kernel), which lsof obviously doesn't do. There is no
>>> easy workaround here, except by modifying lsof.
>>> For example, the warning about KASSERT is because lsof's headers don't
>>> include the required headers for this macro. And gcc is apparently not
>>> smart enough to generate warnings for this. :)
>>> In any case, isn't lsof's dlsof.h header full of special cases already?
>>> What does it matter to add another one?
>>> Besides, even if you fix it in the system headers now, at compile time
>>> you cannot be sure if the user has the correct version of them installed
>>> anyway, so you would still have to work around the problem.
>> We will NOT support clang as the compiler for lsof unless the system headers
>> work the same way as gcc's do.
> Are asking that clang become bug compatible with gcc or that gcc be
> fixed to present the same errors as clang does? As a casual observer I
> really don't expect either to happen soon. (I suspect gcc being fixed
> SLIGHTLY more likely.)
No, just asking that the same headers not generate ERRORS where gcc
doesn't Extra Warnings are fine.
the big one here is the _builtin_ffs() one about signed vs unsigned.
> By it's very nature lsof does a lot of the sort of kernel interaction
> that is normally considered to be unacceptable and requires lots of
> kludges and hacks to do them. I am simply baffled as to why this issue
> is so different other then that it is dependent on the compiler used
> and not the differences between kernels and kernel interfaces.
It's not. It's just that this seems(!) to be a trivial issue to fix
for the folks adding/wanting clang to process all ports.
> On the other hand, I have not done real kernel programming in
> years...not since I was writing kernel code in assembly for VMS about
> 20 years ago, so maybe I am missing some subtleties about this.
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler at lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
More information about the freebsd-current