kernel- or glibc-headers in f9 broken?

[Oliver Falk]

On 12/10/2007 06:40 PM, Paul Howarth wrote:
> Oliver Falk wrote:
>> fyi.
>>
>> In file included from /usr/include/asm/sigcontext.h:4,
>>                  from /usr/include/bits/sigcontext.h:28,
>>                  from /usr/include/signal.h:333,
>>                  from /usr/include/sys/wait.h:31,
>>                  from ../include/conf.h:95,
>>                  from pr_fnmatch.c:38:
>> /usr/include/asm/types.h:6: error: conflicting types for 'mode_t'
>> /usr/include/sys/types.h:72: error: previous declaration of 'mode_t' was
>> here
>> make[2]: *** [pr_fnmatch.o] Error 1
>>
>> Is what I see, if I try to rebuild proftpd in f9.
>>
>> [oliver at pils proftpd]$ rpm -qf /usr/include/sys/types.h
>> /usr/include/asm/types.h
>> glibc-headers-2.7-2
>> kernel-headers-2.6.24-0.79.rc4.git5.fc9
>>
>> Funny:
>> [oliver at pils proftpd]$  grep mode_t /usr/include/asm/types.h
>> typedef unsigned short umode_t;
>>
>> This is a i386 box!
> 
> The configure script looks for a definition of umode_t via its default
> set of includes and if it doesn't find it, does this:
> 
> #define umode_t mode_t
> 
> This then becomes a problem when the umode_t type is used in the source
> code after including a header file such as <signal.h>, which *does* pull
> in a valid definition of umode_t.
> 
> F9.i386 has recently dropped umode_t from the default include files and
> this has triggered the problem. I've seen this before on ppc64 when I
> had a similar problem with gnome-libs.
> 
> As a workaround, I hacked together the (icky) patch attached this
> afternoon.

WorksForMe(tm). :-)


-of