kernel- or glibc-headers in f9 broken?

[Paul Howarth]

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.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proftpd-1.3.1-find-umode_t.patch
Type: text/x-patch
Size: 6785 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20071210/6585fecc/attachment.bin>