[patch] nptl: remove unneeded libc-lock.h include

Timo Teräs timo.teras at iki.fi
Tue Apr 20 18:54:32 UTC 2010


Laurent Bercot wrote:
>>>>> -#include <bits/libc-lock.h>
>>>> I guess this is required for STDIO_FUTEXES, or am I wrong ?
>>> Not needed. If STDIO_FUTEXES is defined, the file includes
>>> later on bits/stdio-lock.h which ends up including the
>>> libc-lock.h.
>>>
>> ok, that's fine.
> 
>  Not wanting to interfere, but shouldn't including an unneeded
> .h file be totally harmless? Shouldn't .h files be independent,
> self-contained entities that declare certain symbol and macros
> and don't break, just declare too much, if you include more than
> is necessary?
> 
>  Or should this only be guaranteed only for "public" .h files
> designed to be used by applications, while "internal" libc headers
> can do some black voodoo?
>  Sounds kinda brittle and hard to maintain if it's the case.

Yes, that's what I was assuming too. But it looks like libc-lock.h
is taken from glibc, and never really ported to uclibc properly.
In matter of fact, many sysdeps headers are like that. Some are
even in uclibc, but never used.

Some should clean up the headers. But it's slightly complicated.
Especially if you want some easy way to sync with glibc. This
patch just reverts the immediate damage I introduced. But yes,
someone should fix up the headers properly.

- Timo


More information about the uClibc mailing list