building of xrandr against uClibc

[Eirik Byrkjeflot Anonsen]

walter harms <wharms at bfs.de> writes:

> 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 ?

Two possibilities:

1: The relevant header file does not get included when using glibc.

2: glibc only declares this function if requested.

The man page seems to indicate that 2 is true (You need to #define
_GNU_SOURCE).  But Mikhail's response indicates that 1 is true.

eirik