unistd.h, stdio.h, pthread.h and strings.h all cause redundant redeclarations.

[Miles Lane]

I have just submitted this bug report in the gnatsweb.

> Any clue as to why I am getting the following warnings?

> /usr/include/unistd.h:956: warning: previous declaration of `setkey'
> In file included from def.h:28,
>                  from include.c:26:
> /usr/include/stdio.h:126: warning: redundant redeclaration of `rename'
> in same scope
> /usr/include/unistd.h:982: warning: previous declaration of `rename'
> /usr/include/stdio.h:588: warning: redundant redeclaration of `ctermid'
> in same scope
> /usr/include/unistd.h:975: warning: previous declaration of `ctermid'
> /usr/include/stdio.h:594: warning: redundant redeclaration of `cuserid'
> in same scope
> /usr/include/unistd.h:979: warning: previous declaration of `cuserid'
> In file included from ../../exports/include/X11/Xthreads.h:196,
>                  from locking.h:36,
>                  from XlibInt.c:41:
> /usr/include/pthread.h:539: warning: redundant redeclaration of
> `pthread_atfork' in same scope
> /usr/include/unistd.h:1001: warning: previous declaration of
> `pthread_atfork'

> /usr/include/strings.h:29: warning: redundant redeclaration of `bcmp' in
> same scope
> /usr/include/strings.h:32: warning: redundant redeclaration of `bcopy'
> in same scope
> /usr/include/strings.h:35: warning: redundant redeclaration of `bzero'
> in same scope
> /usr/include/strings.h:39: warning: redundant redeclaration of `ffs' in
> same scope
> /usr/include/strings.h:42: warning: redundant redeclaration of `index'
> in same scope
> /usr/include/strings.h:45: warning: redundant redeclaration of `rindex'
> in same scope
> /usr/include/strings.h:48: warning: redundant redeclaration of
> `strcasecmp' in same scope
> /usr/include/strings.h:52: warning: redundant redeclaration of
> `strncasecmp' in same scope

> /usr/include/unistd.h, /usr/include/stdio.h and /usr/include/strings.h
> all are supplied by glibc-devel-2.1.3-18.3mdk.

... and all ignore each other's inclusion.  This is another glibc issue.
It also happens with libc5, so it's been around for a while.