building of xrandr against uClibc

[Stephan Raue-2]

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@.../msg02003.html


thank you,

Stephan

--
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Adam Jackson]

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@.../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


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Eirik Byrkjeflot Anonsen]

Adam Jackson <ajax@...> 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@.../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
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[walter harms-2]

Eirik Byrkjeflot Anonsen schrieb:

> Adam Jackson <ajax@...> 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@.../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


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Yann Droneaud]

Le mardi 03 novembre 2009 à 13:04 -0500, Adam Jackson a écrit :

> 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@.../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
>

It's indeed a header bug.

BTW, the policy variable is never really used in the code, it's only set
while parsing for option, never read. So there's something wrong in the
code.

Regards.

--
Yann Droneaud



_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Mikhail Gusarov-3]

Twas brillig at 13:04:37 03.11.2009 UTC-05 when ajax@... did gyre and gimble:

 AJ> Pretty sure this is a uclibc header bug.  glibc has exactly the
 AJ> same definitions in <bits/sched.h> and does not have this problem.
 AJ> Which I already said the last time this was brought up:

------------------------------------------------------------------------
#include <sched.h>

typedef enum baz {
    clone
} baz_baz;
------------------------------------------------------------------------

does not compile.

Looks like in uClibc setup some of headers indirectly include <sched.h>
(I don't have working uClibc-based build environment right now to test
it).

Error can be easily reproduced with glibc by adding #include <sched.h>
to the xrandr.c

--
  http://fossarchy.blogspot.com/


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Eirik Byrkjeflot Anonsen]

walter harms <wharms@...> writes:

> Eirik Byrkjeflot Anonsen schrieb:
>> Adam Jackson <ajax@...> 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@.../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
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Yann Droneaud]

This was dead code after all.
The usage message regarding those options was already commented out.

This could be a fix for bug #12958

---
 xrandr.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xrandr.c b/xrandr.c
index f7eba11..242ed06 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -210,9 +210,11 @@ reflection_name (Rotation rotation)
 }
 
 #if HAS_RANDR_1_2
+#if 0
 typedef enum _policy {
     clone, extend
 } policy_t;
+#endif
 
 typedef enum _relation {
     left_of, right_of, above, below, same_as,
@@ -2062,7 +2064,9 @@ main (int argc, char **argv)
     int ret = 0;
 #if HAS_RANDR_1_2
     output_t *output = NULL;
+#if 0
     policy_t policy = clone;
+#endif
     Bool     setit_1_2 = False;
     Bool     query_1_2 = False;
     Bool modeit = False;
@@ -2436,6 +2440,7 @@ main (int argc, char **argv)
     setit_1_2 = True;
     continue;
  }
+#if 0
  if (!strcmp ("--clone", argv[i])) {
     policy = clone;
     setit_1_2 = True;
@@ -2446,6 +2451,7 @@ main (int argc, char **argv)
     setit_1_2 = True;
     continue;
  }
+#endif
  if (!strcmp ("--auto", argv[i])) {
     if (output)
     {
--
1.6.0.2



_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg