[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: kernel- or glibc-headers in f9 broken?

Matthias (owner of proftpd AFAIK)! Did you see this mail/patch?


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 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 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.

Oliver Falk
UNIX/Linux Systems Engineer
Mail: oliver linux-kernel at
Phone: +43 (664) 838 59 25

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]