| Submitter | Xiaofeng Yan |
|---|---|
| Date | Feb. 6, 2012, 6:41 a.m. |
| Message ID | <1624cca695c5baf08d376297f7278732dbcbfba6.1328509284.git.xiaofeng.yan@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/20767/ |
| State | New |
| Headers | show |
Comments
On Mon, 2012-02-06 at 14:41 +0800, Xiaofeng Yan wrote: > From: Xiaofeng Yan <xiaofeng.yan@windriver.com> > > function "g_qsort_with_data" has two kinds of realization. One calls qsort_r > from libglib, the other realize itself. > qsort_r from libglib cause sort error. > For fixing this problem no checking "qsort_r" in configure.ac. > > [YOCTO #1959] This description doesn't make much sense. libglib is part of glib-2.0 itself; I guess you meant to say that qsort_r is from libc6. But, even leaving that aside, if qsort_r is broken then the appropriate patch would be to fix it, not just to hack glib to use a standalone implementation. So this patch seems like the wrong thing by any measure. Does glibc's own testsuite also have failures for qsort_r? p.
On Mon, Feb 6, 2012 at 1:13 AM, Phil Blundell <philb@gnu.org> wrote: > On Mon, 2012-02-06 at 14:41 +0800, Xiaofeng Yan wrote: >> From: Xiaofeng Yan <xiaofeng.yan@windriver.com> >> >> function "g_qsort_with_data" has two kinds of realization. One calls qsort_r >> from libglib, the other realize itself. >> qsort_r from libglib cause sort error. >> For fixing this problem no checking "qsort_r" in configure.ac. >> >> [YOCTO #1959] > > This description doesn't make much sense. libglib is part of glib-2.0 > itself; I guess you meant to say that qsort_r is from libc6. But, even > leaving that aside, if qsort_r is broken then the appropriate patch > would be to fix it, not just to hack glib to use a standalone > implementation. So this patch seems like the wrong thing by any > measure. > > Does glibc's own testsuite also have failures for qsort_r? glibc one works ok last time I checked however uclibc does not implement it > > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On 02/06/2012 04:34 PM, Khem Raj wrote: > On Mon, Feb 6, 2012 at 1:13 AM, Phil Blundell<philb@gnu.org> wrote: >> On Mon, 2012-02-06 at 14:41 +0800, Xiaofeng Yan wrote: >>> From: Xiaofeng Yan<xiaofeng.yan@windriver.com> >>> >>> function "g_qsort_with_data" has two kinds of realization. One calls qsort_r >>> from libglib, the other realize itself. >>> qsort_r from libglib cause sort error. >>> For fixing this problem no checking "qsort_r" in configure.ac. >>> >>> [YOCTO #1959] >> This description doesn't make much sense. libglib is part of glib-2.0 >> itself; I guess you meant to say that qsort_r is from libc6. But, even >> leaving that aside, if qsort_r is broken then the appropriate patch >> would be to fix it, not just to hack glib to use a standalone >> implementation. So this patch seems like the wrong thing by any >> measure. >> >> Does glibc's own testsuite also have failures for qsort_r? > glibc one works ok last time I checked however uclibc does not implement it Yes, it does. It was implemented somewhere in between 0.9.32 and 0.9.33 [1]. Last time I've checked it even worked fine with glib-2.0. You just need to change glib_cv_have_qsort to yes in meta/site/common-uclibc. /ptw [1] http://git.uclibc.org/uClibc/commit/?id=515d54433138596e81267237542bd9168b8cc787
On Mon, Feb 6, 2012 at 11:13 AM, Peter Tworek <tworaz666@gmail.com> wrote: > Yes, it does. It was implemented somewhere in between 0.9.32 and 0.9.33 [1]. > Last time I've checked it even worked fine with glib-2.0. You just need to > change glib_cv_have_qsort to yes in meta/site/common-uclibc. yes I was merely pointing out the need since we still dont have 0.9.33 in metadata
Patch
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/no-check-qsort_r.patch b/meta/recipes-core/glib-2.0/glib-2.0/no-check-qsort_r.patch new file mode 100644 index 0000000..99e229c --- /dev/null +++ b/meta/recipes-core/glib-2.0/glib-2.0/no-check-qsort_r.patch @@ -0,0 +1,61 @@ +Upstream-Status: Pending + +function "g_qsort_with_data" has two kinds of realization. One calls qsort_r +from libglib, the other realize itself. +qsort_r from libglib cause sort error. Don't check qsort_r for fixing this problem. + +Xiaofeng Yan <xiaofeng.yan@windriver.com> + +Index: glib-2.30.0/configure.ac +=================================================================== +--- a/configure.ac 2012-02-06 11:15:37.885295264 +0800 ++++ b/configure.ac.new 2012-02-06 11:16:04.239795382 +0800 +@@ -584,47 +584,7 @@ + dnl don't use AC_CHECK_FUNCS here, otherwise HAVE_QSORT_R will + dnl be automatically defined, which we don't want to do + dnl until we have checked this function is actually usable +-AC_CHECK_FUNC([qsort_r]) +- +-# BSD has a qsort_r with wrong argument order +-if test x$ac_cv_func_qsort_r = xyes ; then +- AC_CACHE_CHECK([if qsort_r uses glibc compatible argument order], glib_cv_have_qsort_r, [ +- AC_RUN_IFELSE([AC_LANG_SOURCE([[ +- #define _GNU_SOURCE +- #include <stdlib.h> +- +- static int +- cmp (const void *a, const void *b, void *c) +- { +- const int *ia = a; +- const int *ib = b; +- +- if (*ia < *ib) +- return -1; +- else if (*ia > *ib) +- return 1; +- else +- return 0; +- } +- +- int +- main (int argc, char **argv) +- { +- int arr[3] = { 1, 2, 0 }; +- int d = 3; +- +- qsort_r (arr, 3, sizeof (int), cmp, &d); +- +- if (arr[0] == 0 && arr[1] == 1 && arr[2] == 2) +- return 0; +- else +- return 1; +- }]])],[glib_cv_have_qsort_r=yes],[glib_cv_have_qsort_r=no])]) +-fi +- +-if test x$glib_cv_have_qsort_r = xyes ; then +- AC_DEFINE(HAVE_QSORT_R, 1, [Define to 1 if you have the 'qsort_r' function]) +-fi ++#AC_CHECK_FUNC([qsort_r]) + + AC_CHECK_SIZEOF(char) + AC_CHECK_SIZEOF(short)