walter harms <[email protected]> writes: > Eirik Byrkjeflot Anonsen schrieb: >> Adam Jackson <[email protected]> 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/[email protected]/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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
