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. WorksForMe(tm). :-) -of -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
