Ping. Original post: http://lists.uclibc.org/pipermail/uclibc/2011-June/045408.html
>Hi, > >>Maybe a fix in uClibc is more pragmatic, but definitely not one with a >>condition on IN_LIBGCC2, since IN_LIBGCC2 is part of the user's >namespace >>so installed system headers should not use it in any way. > >So after some discussion on the gcc lists about this: >http://gcc.gnu.org/ml/gcc-help/2011-06/msg00189.html > >I proposed to define __IN_LIBGCC2 for bfin parts during libgcc build in >gcc (which they accept) and then I would like to apply the below patch >to uClibc. > >Is this acceptable? > >Thanks, >Stu > >Index: uClibc/libc/sysdeps/linux/bfin/sys/ucontext.h >=================================================================== >--- uClibc/libc/sysdeps/linux/bfin/sys/ucontext.h (revision 5456) >+++ uClibc/libc/sysdeps/linux/bfin/sys/ucontext.h (working copy) >@@ -33,6 +33,7 @@ typedef int greg_t; > /* Container for all general registers. */ > typedef greg_t gregset_t[NGREG]; > >+#ifndef __IN_LIBGCC2 > /* Number of each register is the `gregset_t' array. */ > enum > { >@@ -131,6 +132,7 @@ enum > REG_SEQSTAT = 46 > #define REG_SEQSTAT REG_SEQSTAT > }; >+#endif > > /* Context to describe whole processor state. */ > typedef struct > >_______________________________________________ >uClibc mailing list >uClibc@uclibc.org >http://lists.busybox.net/mailman/listinfo/uclibc _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc