building of xrandr against uClibc

[Eirik Byrkjeflot Anonsen]

Adam Jackson <ajax at nwnk.net> writes:

> On Tue, 2009-11-03 at 02:14 +0100, Stephan Raue wrote:
>> Hi all,
>> 
>> can anyone fix compiling of xrandr against uClibc (reported in 
>> http://bugs.freedesktop.org/show_bug.cgi?id=12958)
>> 
>> see also:
>> http://osdir.com/ml/linux.lfs.hardened/2008-04/msg00009.html
>> http://lists.x.org/archives/xorg-devel/2009-February/000281.html
>> http://bugs.gentoo.org/197013
>> http://www.mail-archive.com/hlfs-dev@linuxfromscratch.org/msg02003.html
>
> Pretty sure this is a uclibc header bug.  glibc has exactly the same
> definitions in <bits/sched.h> and does not have this problem.  Which I
> already said the last time this was brought up:
>
> http://lists.x.org/archives/xorg-devel/2009-March/000365.html
>
> - ajax

If you think that it is a bug in the uclibc headers to declare the
clone() function at all, your argument is valid.  However, I think the
comment in the bug ("why cant this symbol get renamed so that things
compile?") is also valid (regardless of who is "at fault").  Renaming
the enum value to avoid the potential conflict may be the better option
anyway...

And I don't think glibc's behaviour is a normative reference :)  (If
someone could find a specification that clearly says whether it is
disallowed to declare clone(), that would be nice...)

eirik