[PATCH] resolv: fix res_close not to hang with ipv6

2011-04-08 Thread Timo Teräs 
The memory release loop is missing an obvious counter increment.

Signed-off-by: Timo Teräs timo.te...@iki.fi
---
 libc/inet/resolv.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libc/inet/resolv.c b/libc/inet/resolv.c
index 47bab75..1e394d4 100644
--- a/libc/inet/resolv.c
+++ b/libc/inet/resolv.c
@@ -3006,9 +3006,9 @@ void res_close(void)
 #ifdef __UCLIBC_HAS_IPV6__
{
char *p1 = (char*) (_res.nsaddr_list[0]);
-   int m = 0;
+   int m;
/* free nsaddrs[m] if they do not point to nsaddr_list[x] */
-   while (m  ARRAY_SIZE(_res._u._ext.nsaddrs)) {
+   for (m = 0; m  ARRAY_SIZE(_res._u._ext.nsaddrs); m++) {
char *p2 = (char*)(_res._u._ext.nsaddrs[m]);
if (p2  p1 || (p2 - p1)  sizeof(_res.nsaddr_list))
free(p2);
-- 
1.7.1

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

patch to fix build issue in uClibc testsuite

2011-04-08 Thread Jian Peng 
In test/Rules.mak, $(KERNEL_HEADERS) will be checked and used to generate
$(KERNEL_INCLUDES) based on absolute or relative path.

The problem is that this check assumes that $(KERNEL_HEADERS) is
single word like /user/me/kernel/include, in case that it is
/user/me/kernel/include -I/user/me/kernel/arch/mips/include,
$(KERNEL_INCLUDES) will be wrong and leads to unable to find out
kernel header files in build process.

Here I reworked the logic to check each path in $(KERNEL_HEADERS) 
individually, then combine them.

Signed-off-by: Jian Peng jipeng2...@gmail.com
---
 test/Rules.mak |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/test/Rules.mak b/test/Rules.mak
index 2131a7b..e144b0f 100644
--- a/test/Rules.mak
+++ b/test/Rules.mak
@@ -46,14 +46,10 @@ export TARGET_ARCH
 RM_R = $(Q)$(RM) -r
 LN_S = $(Q)$(LN) -fs

+# handle absolute and relative path on each path in $(KERNEL_HEADERS) 
separately
 ifneq ($(KERNEL_HEADERS),)
-ifeq ($(patsubst /%,/,$(KERNEL_HEADERS)),/)
-# Absolute path in KERNEL_HEADERS
-KERNEL_INCLUDES += -I$(KERNEL_HEADERS)
-else
-# Relative path in KERNEL_HEADERS
-KERNEL_INCLUDES += -I$(top_builddir)$(KERNEL_HEADERS)
-endif
+KERNEL_HEADERS := $(patsubst -I%,%,$(KERNEL_HEADERS))
+KERNEL_INCLUDES += $(addprefix -I,$(foreach i,$(KERNEL_HEADERS),$(patsubst 
.%,$(top_builddir).%,$i)))
 endif

 XCOMMON_CFLAGS := -I$(top_builddir)test -D_GNU_SOURCE
--
1.7.4.1



___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

missing libm-test-ulps-mips under test/math/

2011-04-08 Thread Jian Peng 
Under test/math, libm-test-ulps-mips is missing or build for MIPS
is broken

Simply copy it from glibc-ports-2.9/sysdeps/mips/fpu/libm-test-ulps
to fix this.

The patch is attached.


0001-PATCH-v1-math-test-missing-libm-test-ulps-mips.patch
Description: 0001-PATCH-v1-math-test-missing-libm-test-ulps-mips.patch
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Drop GNU make 3.80 compatibility

2011-04-08 Thread Khem Raj 
On Fri, 2011-04-01 at 14:24 -0700, Kevin Cernekee wrote:
 On Fri, Apr 1, 2011 at 1:43 PM, Mike Frysinger vap...@gentoo.org wrote:
  On Fri, Apr 1, 2011 at 11:23 AM, Kevin Cernekee wrote:
  The $(and operator requires GNU make 3.81.  On 3.80 it is a no-op.
  Consequently, strange build problems (failure to compile madvise.c) pop
  up when using make 3.80.
 
  Since nobody else is reporting these types of problems, I'm going to
  guess that I am one of the last remaining holdouts still running 3.80.
  So we might as well officially require 3.81.
 
  if that's the only reason, then let's drop the $(and) usage instead.
 
 A month or two ago, else ifeq broke make 3.80.
 
 I suspect that everybody else is using 3.81/3.82 and so 3.80 is not
 getting any test coverage.  This allows small incompatibilities to
 creep into the Makefiles.
 
 Personally, I'd rather not upgrade because I try to make my release
 buildable on any stock RHEL4/RHEL5 system.  But I don't want to have
 to keep debugging things that only break because I'm using make 3.80.

I think it would be nice to keep it working with make 3.80 even though
its 10 years old. Are these problems widespread ? if not then consider
cooking up a patch :)

-- 
-Khem

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc