Description of problem:
The dummy 'chflags' function in glibc causes issues for autoconf configure
scripts, which treat the fact that there is a chflags() function present as
meaning that there is a usable chflags() function present.  Searching the
glibc-hackers mailing list, this seems to be related to some check-abi work
done a while ago (see
http://sources.redhat.com/ml/libc-hacker/2003-03/msg00052.html  for an example)
A "consistent" ABI is all fine and good, but this doesn't seem to be the way to
get there.

Version-Release number of selected component (if applicable):
glibc-2.3.2-48

How reproducible:
Compile cample program, see that there is no error.

Steps to Reproduce:
1.
2.
3.
    
Actual results:
Program links, causing './configure' to assume there is a usable chflags,
causing later compile errors because there's no actual support for it.
In particular, there's no UF_IMMUTABLE to be found in /usr/include....

Expected results:
A link error, so configure doesn't assume software is present.

Additional info:
A stripped-down version of a standard autoconf-generated test:
AC_CHECK_FUNCS(chflags)

[~]2 cat test-chflag.c
char chflags(); /* actual proto doesn't matter */

char (*f) () = chflags;

int main() {

  return f != chflags;
;
 return 0;
}
[~]2 gcc -o test-chflag test-chflag.c
/tmp/cclUXrNr.o(.text+0x16): In function `main':
: warning: chflags is not implemented and will always fail
[~]2 echo $?
0

so configure then defines HAVE_CHFLAGS and all sorts of hilarity ensues
when code that's inside a #ifdef HAVE_CHFLAGS gets compiled.