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!

-of

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Monday, 10 December 2007 at 18:40, Paul Howarth wrote:
[...]
> As a workaround, I hacked together the (icky) patch attached this afternoon.
>
> Paul.

[...]
> @@ -37144,7 +37296,7 @@
> INSTALL_STRIP=""
> else
>
> - INSTALL_STRIP="-s"
> + INSTALL_STRIP=""
> fi
>
> echo "$as_me:$LINENO: checking whether ${CC-cc} accepts -Wno-long-double" >&5

Unrelated? It's better to add INSTALL_STRIP="" to make call instead.

Regards,
R.

--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

Thx,
Oliver

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Dominik 'Rathann' Mierzejewski wrote:

On Monday, 10 December 2007 at 18:40, Paul Howarth wrote:
[...]

As a workaround, I hacked together the (icky) patch attached this afternoon.

Paul.


[...]

@@ -37144,7 +37296,7 @@
INSTALL_STRIP=""
else

- INSTALL_STRIP="-s"

+ INSTALL_STRIP=""
fi

echo "$as_me:$LINENO: checking whether ${CC-cc} accepts -Wno-long-double" >&5


Unrelated? It's better to add INSTALL_STRIP="" to make call instead.


This bit's just autoconf output in the patched configure script; untidy
but not directly related to the underlying problem.


Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Paul Howarth wrote:

Dominik 'Rathann' Mierzejewski wrote:

On Monday, 10 December 2007 at 18:40, Paul Howarth wrote:
[...]
As a workaround, I hacked together the (icky) patch attached this
afternoon.


Paul.


[...]

@@ -37144,7 +37296,7 @@
INSTALL_STRIP=""
else

- INSTALL_STRIP="-s"

+ INSTALL_STRIP=""
fi

echo "$as_me:$LINENO: checking whether ${CC-cc} accepts
-Wno-long-double" >&5


Unrelated? It's better to add INSTALL_STRIP="" to make call instead.


This bit's just autoconf output in the patched configure script; untidy
but not directly related to the underlying problem.


Sorry, forget what I just said. You're right, this bit's a hangover from
a sed run earlier in my %prep, I'd be better off using
INSTALL_STRIP="" as you say. Good spot.


Cheers, Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list