building of xrandr against uClibc

[walter harms]

Eirik Byrkjeflot Anonsen schrieb:
> 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...)
> 

I have no clue where clone is coming but you may like to know:
glibc/linux also has a syscall called clone, who is that handled ?

re,
 wh