Re: Support for logf, sinf and cosf in libuClibc (uClibc0.9.27)

[Khem Raj]

On 9/20/17 11:50 PM, monika wadekar wrote:

Hi there,

I am trying to build qt-webkit v4.5.3 for ARM platform (iwmmxt) using
uClibc0.9.27 cross toolchain.

However I am getting following errors at the time of running make
(Configure was successfull):

"qt-embedded-linux-opensource-src-4.5.3/lib/libQtGui.so: undefined
reference to `logf'"
"qt-embedded-linux-opensource-src-4.5.3/lib/libQtGui.so: undefined
reference to `cosf'"
"qt-embedded-linux-opensource-src-4.5.3/lib/libQtGui.so: undefined
reference to `sinf'"

I think the defination of these functions is not present in uClibc0.9.27.
If my understanding is correct, can you please help me add these
definations in uClibc v0.9.27. Is there any workaround/patch to get rid of
these errors.

Kindly note that I do not have an option to use any other uClibc version
due to qt version and ARM processor dependencies.

Any help/pointers will be highly appreciated.


These should be coming from libm, so first thing is to check if your 
linker cmdline has -lm or not. if it does then these are really missing, 
I would suggest to look at latest uclibc master and do the needed backports.

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

Re: [PATCH] ldso/ARC: fix DT_RELACOUNT handling

[Khem Raj]

On Fri, May 20, 2016 at 1:26 AM, Vineet Gupta
 wrote:
>> This is ok
>
> Is this is question

no, its a comment. I know its a rela ABI
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ldso/ARC: fix DT_RELACOUNT handling

[Khem Raj]

On Thu, May 19, 2016 at 11:56 PM, Vineet Gupta
 wrote:
> From: Cupertino Miranda 
>
> Wih new bintuils supporting DT_RELACOUNT, ldso was crashing as it was
> parsing relocs incorrectly.
>
> Apparently that code ran for first time and was never tested.
>
> Signed-off-by: Vineet Gupta 
> ---
>  ldso/ldso/arc/dl-sysdep.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ldso/ldso/arc/dl-sysdep.h b/ldso/ldso/arc/dl-sysdep.h
> index b6bda9d14691..caece997d254 100644
> --- a/ldso/ldso/arc/dl-sysdep.h
> +++ b/ldso/ldso/arc/dl-sysdep.h
> @@ -166,7 +166,7 @@ static __always_inline void
>  elf_machine_relative (Elf32_Addr load_off, const Elf32_Addr rel_addr,
>   Elf32_Word relative_count)
>  {
> -Elf32_Rel * rpnt = (void *) rel_addr;
> +Elf32_Rela * rpnt = (void *) rel_addr;

This is ok

> --rpnt;
> do {
> Elf32_Addr *const reloc_addr = (void *) (load_off + 
> (++rpnt)->r_offset);
> --
> 2.5.0
>
> ___
> 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

Re: uClibc-ng 1.0.12 released

[Khem Raj]

On Mon, Feb 1, 2016 at 8:16 AM, Waldemar Brodkorb  wrote:
> Hi Embedded Hackers,
>
> exactly one year after the first uClibc-ng release I finished with
> the 13'th release of uClibc-ng. It contains a fix for a possible DoS
> attack in the resolver code, so you should better update.
>
> The release contains various bugfixes and new features.

is there a shortlog published somewhere

>
> Special thanks to Leonid Lisovskiy and Daniel Fahlgren doing some
> code review regarding libdl and resolver code.
>
> Test results for the testsuite will follow in the next days and can
> be found here:
> http://embedded-test.org/

Thanks for doing it. I will have it up for OE soon
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: syncfs() in uClibc

[Khem Raj]

On Sat, Jan 2, 2016 at 1:47 PM, Anthony G. Basile
 wrote:
> Hi everyone,
>
> We need to get syncfs() into uClibc because its needed for busybox [1]
> and (I believe) systemd.  I've seen patches for this go to openembedded
> and uclibc-ng, but I'm not sure if any patch has come to uClibc itself.
>  There's a set of three patches in uclibc-ng (the original port of
> syncfs() by Bartosz Golaszewski) and a follow up by Thomas Petazzoni and
> myself.
>
> To be honest, I'm lost in uClibc patch queue.  Should I (re?)submit
> Bartosz + Thomas + my patches here?  I'd like to see them get into git
> master and the 0.9.33 branch.

Please do submit them here. It will get into uclibc-ng

>
> Ref.
> [1] https://bugs.gentoo.org/show_bug.cgi?id=567598
>
> --
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
> ___
> 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

Re: [PATCH] Replace MIPS specific memcpy.S/memset.S with version from glibc/newlib.

[Khem Raj]

Hi Steve

On Mon, Dec 21, 2015 at 1:22 PM, Steve Ellcey  wrote:
> These MIPS specific versions of memcpy.S and memset.S are faster than
> the current ones and match what is in newlib and glibc.  They also have
> support for the mips32r6 and mips64r6 architectures.
>

what is the size impact ? Would be nice to have that report as well.

> Signed-off-by: Steve Ellcey 
> ---
>  libc/string/mips/memcpy.S | 1051 
> +++--
>  libc/string/mips/memset.S |  516 --
>  2 files changed, 1229 insertions(+), 338 deletions(-)
>
> diff --git a/libc/string/mips/memcpy.S b/libc/string/mips/memcpy.S
> index 48c4f2a..2a187ef 100644
> --- a/libc/string/mips/memcpy.S
> +++ b/libc/string/mips/memcpy.S
> @@ -1,6 +1,5 @@
> -/* Copyright (C) 2002, 2003 Free Software Foundation, Inc.
> +/* Copyright (C) 2012-2015 Free Software Foundation, Inc.
> This file is part of the GNU C Library.
> -   Contributed by Hartvig Ekner , 2002.
>
> The GNU C Library is free software; you can redistribute it and/or
> modify it under the terms of the GNU Lesser General Public
> @@ -13,243 +12,861 @@
> Lesser General Public License for more details.
>
> You should have received a copy of the GNU Lesser General Public
> -   License along with the GNU C Library; if not, see
> +   License along with the GNU C Library.  If not, see
> .  */
>
> -#include 
> -#include 
> -#include 
> +#ifdef ANDROID_CHANGES
> +# include "machine/asm.h"
> +# include "machine/regdef.h"
> +# define USE_MEMMOVE_FOR_OVERLAP
> +# define PREFETCH_LOAD_HINT PREFETCH_HINT_LOAD_STREAMED
> +# define PREFETCH_STORE_HINT PREFETCH_HINT_PREPAREFORSTORE
> +#elif _LIBC
> +# include 
> +# include 
> +# include 
> +# define PREFETCH_LOAD_HINT PREFETCH_HINT_LOAD_STREAMED
> +# define PREFETCH_STORE_HINT PREFETCH_HINT_PREPAREFORSTORE
> +#elif defined _COMPILING_NEWLIB
> +# include "machine/asm.h"
> +# include "machine/regdef.h"
> +# define PREFETCH_LOAD_HINT PREFETCH_HINT_LOAD_STREAMED
> +# define PREFETCH_STORE_HINT PREFETCH_HINT_PREPAREFORSTORE
> +#else
> +# include 
> +# include 
> +#endif
> +
> +#if (_MIPS_ISA == _MIPS_ISA_MIPS4) || (_MIPS_ISA == _MIPS_ISA_MIPS5) || \
> +(_MIPS_ISA == _MIPS_ISA_MIPS32) || (_MIPS_ISA == _MIPS_ISA_MIPS64)
> +# ifndef DISABLE_PREFETCH
> +#  define USE_PREFETCH
> +# endif
> +#endif
> +
> +#if defined(_MIPS_SIM) && ((_MIPS_SIM == _ABI64) || (_MIPS_SIM == _ABIN32))
> +# ifndef DISABLE_DOUBLE
> +#  define USE_DOUBLE
> +# endif
> +#endif
> +
> +/* Some asm.h files do not have the L macro definition.  */
> +#ifndef L
> +# if _MIPS_SIM == _ABIO32
> +#  define L(label) $L ## label
> +# else
> +#  define L(label) .L ## label
> +# endif
> +#endif
> +
> +/* Some asm.h files do not have the PTR_ADDIU macro definition.  */
> +#ifndef PTR_ADDIU
> +# ifdef USE_DOUBLE
> +#  define PTR_ADDIUdaddiu
> +# else
> +#  define PTR_ADDIUaddiu
> +# endif
> +#endif
> +
> +/* Some asm.h files do not have the PTR_SRA macro definition.  */
> +#ifndef PTR_SRA
> +# ifdef USE_DOUBLE
> +#  define PTR_SRA  dsra
> +# else
> +#  define PTR_SRA  sra
> +# endif
> +#endif
> +
> +/* New R6 instructions that may not be in asm.h.  */
> +#ifndef PTR_LSA
> +# if _MIPS_SIM == _ABI64
> +#  define PTR_LSA  dlsa
> +# else
> +#  define PTR_LSA  lsa
> +# endif
> +#endif
> +
> +/*
> + * Using PREFETCH_HINT_LOAD_STREAMED instead of PREFETCH_LOAD on load
> + * prefetches appears to offer a slight preformance advantage.
> + *
> + * Using PREFETCH_HINT_PREPAREFORSTORE instead of PREFETCH_STORE
> + * or PREFETCH_STORE_STREAMED offers a large performance advantage
> + * but PREPAREFORSTORE has some special restrictions to consider.
> + *
> + * Prefetch with the 'prepare for store' hint does not copy a memory
> + * location into the cache, it just allocates a cache line and zeros
> + * it out.  This means that if you do not write to the entire cache
> + * line before writing it out to memory some data will get zero'ed out
> + * when the cache line is written back to memory and data will be lost.
> + *
> + * Also if you are using this memcpy to copy overlapping buffers it may
> + * not behave correctly when using the 'prepare for store' hint.  If you
> + * use the 'prepare for store' prefetch on a memory area that is in the
> + * memcpy source (as well as the memcpy destination), then you will get
> + * some data zero'ed out before you have a chance to read it and data will
> + * be lost.
> + *
> + * If you are going to use this memcpy routine with the 'prepare for store'
> + * prefetch you may want to set USE_MEMMOVE_FOR_OVERLAP in order to avoid
> + * the problem of running memcpy on overlapping buffers.
> + *
> + * There are ifdef'ed sections of this memcpy to make sure that it does not
> + * do prefetches on cache lines that are not going to be completely written.
> + * This code is only needed and only 

[PATCH 6/9] ldso: limited support for $ORIGIN in rpath

[Khem Raj]

From: Junling Zheng <zhengjunl...@huawei.com>

Derived from:
http://lists.busybox.net/pipermail/uclibc/2011-March/045003.html

However, the above patch introduced '_dl_strchr' in ldso/ldso/dl-elf.c,
and caused the following undefined referencing compiling error:

  | .../libdl.a(libdl.os): In function `search_for_named_library':
  | .../dl-elf.c:156: undefined reference to `_dl_strchr'
  | collect2: error: ld returned 1 exit status

This problem would be reproduced through compiling gdb in static mode
using uclibc.

So, add the definition of '_dl_strchr' to fix it. The '_dl_strstr' is
added as well.

Upstream-Status: Submitted

Signed-off-by: Timo Teräs 
Signed-off-by: Junling Zheng <zhengjunl...@huawei.com>
Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 ldso/include/dl-string.h |  2 ++
 ldso/ldso/dl-elf.c   | 79 +---
 ldso/ldso/ldso.c | 18 +--
 3 files changed, 59 insertions(+), 40 deletions(-)

diff --git a/ldso/include/dl-string.h b/ldso/include/dl-string.h
index aacad10..14ae617 100644
--- a/ldso/include/dl-string.h
+++ b/ldso/include/dl-string.h
@@ -204,7 +204,9 @@ static __always_inline char * 
_dl_get_last_path_component(char *path)
 # define _dl_strcat strcat
 # define _dl_strcpy strcpy
 # define _dl_strcmp strcmp
+# define _dl_strchr strchr
 # define _dl_strrchr strrchr
+# define _dl_strstr strstr
 # define _dl_memcpy memcpy
 # define _dl_memcmp memcmp
 # define _dl_memset memset
diff --git a/ldso/ldso/dl-elf.c b/ldso/ldso/dl-elf.c
index 5631905..6ab7afe 100644
--- a/ldso/ldso/dl-elf.c
+++ b/ldso/ldso/dl-elf.c
@@ -133,56 +133,60 @@ _dl_protect_relro (struct elf_resolve *l)
  * in uClibc/ldso/util/ldd.c */
 static struct elf_resolve *
 search_for_named_library(const char *name, unsigned rflags, const char 
*path_list,
-   struct dyn_elf **rpnt)
+   struct dyn_elf **rpnt, const char* origin)
 {
-   char *path, *path_n, *mylibname;
+   char *mylibname;
+   const char *p, *pn;
struct elf_resolve *tpnt;
-   int done;
+   int plen;
 
if (path_list==NULL)
return NULL;
 
-   /* We need a writable copy of this string, but we don't
-* need this allocated permanently since we don't want
-* to leak memory, so use alloca to put path on the stack */
-   done = _dl_strlen(path_list);
-   path = alloca(done + 1);
-
/* another bit of local storage */
mylibname = alloca(2050);
 
-   _dl_memcpy(path, path_list, done+1);
-
/* Unlike ldd.c, don't bother to eliminate double //s */
 
/* Replace colons with zeros in path_list */
/* : at the beginning or end of path maps to CWD */
/* :: anywhere maps CWD */
/* "" maps to CWD */
-   done = 0;
-   path_n = path;
-   do {
-   if (*path == 0) {
-   *path = ':';
-   done = 1;
+   for (p = path_list; p != NULL; p = pn) {
+   pn = _dl_strchr(p + 1, ':');
+   if (pn != NULL) {
+   plen = pn - p;
+   pn++;
+   } else
+   plen = _dl_strlen(p);
+
+   if (plen >= 7 && _dl_memcmp(p, "$ORIGIN", 7) == 0) {
+   int olen;
+   if (rflags && plen != 7)
+   continue;
+   if (origin == NULL)
+   continue;
+   for (olen = _dl_strlen(origin) - 1; olen >= 0 && 
origin[olen] != '/'; olen--)
+   ;
+   if (olen <= 0)
+   continue;
+   _dl_memcpy([0], origin, olen);
+   _dl_memcpy([olen], p + 7, plen - 7);
+   mylibname[olen + plen - 7] = 0;
+   } else if (plen != 0) {
+   _dl_memcpy(mylibname, p, plen);
+   mylibname[plen] = 0;
+   } else {
+   _dl_strcpy(mylibname, ".");
}
-   if (*path == ':') {
-   *path = 0;
-   if (*path_n)
-   _dl_strcpy(mylibname, path_n);
-   else
-   _dl_strcpy(mylibname, "."); /* Assume current 
dir if empty path */
-   _dl_strcat(mylibname, "/");
-   _dl_strcat(mylibname, name);
+   _dl_strcat(mylibname, "/");
+   _dl_strcat(mylibname, name);
 #ifdef __LDSO_SAFE_RUNPATH__
-   if (*mylibname == '/')
+   if (*mylibname == '/')
 #endif
-   if ((tpnt = _dl_load_elf_shared_library(rflags, 
rpnt, mylibname)) != NULL)
-   return 

[PATCH 8/9] fcntl: Add AT_EMPTY_PATH for all and O_PATH for arm

[Khem Raj]

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 include/fcntl.h | 3 +++
 libc/sysdeps/linux/arm/bits/fcntl.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/include/fcntl.h b/include/fcntl.h
index 11000dd..8a7ad9b 100644
--- a/include/fcntl.h
+++ b/include/fcntl.h
@@ -65,6 +65,9 @@ __BEGIN_DECLS
 # define AT_SYMLINK_FOLLOW 0x400   /* Follow symbolic links.  */
 # define AT_EACCESS0x200   /* Test access permitted for
   effective IDs, not real IDs.  */
+# ifdef __USE_GNU
+#  define AT_EMPTY_PATH 0x1000  /* Allow empty relative pathname.  */
+# endif
 #endif
 
 /* Do the file control operation described by CMD on FD.
diff --git a/libc/sysdeps/linux/arm/bits/fcntl.h 
b/libc/sysdeps/linux/arm/bits/fcntl.h
index aedc154..c6ba958 100644
--- a/libc/sysdeps/linux/arm/bits/fcntl.h
+++ b/libc/sysdeps/linux/arm/bits/fcntl.h
@@ -50,6 +50,7 @@
 # define O_DIRECT  020 /* Direct disk access.  */
 # define O_NOATIME 0100 /* Do not set atime.  */
 # define O_CLOEXEC 0200 /* Set close_on_exec.  */
+# define O_PATH   01000 /* Resolve pathname but do not open file.  */
 #endif
 
 /* For now Linux has synchronisity options for data and read operations.
-- 
2.6.2

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

[PATCH 7/9] nptl/atfork: Hide pthread_atfork in shared versions

[Khem Raj]

Signed-off-by: Khem Raj <raj.k...@gmail.com>
Upstream-Status: Pending
---
 libpthread/nptl/Makefile.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libpthread/nptl/Makefile.in b/libpthread/nptl/Makefile.in
index 55eeba2..8cb8fa9 100644
--- a/libpthread/nptl/Makefile.in
+++ b/libpthread/nptl/Makefile.in
@@ -16,6 +16,7 @@ libc-shared-routines-y = forward.c libc-cancellation.c
 libc-static-routines-y = alloca_cutoff.c libc-cancellation.c
 libpthread-shared-only-routines-y = version.c
 libpthread-static-only-routines-y = pthread_atfork.c
+
 libpthread-routines- += $(notdir $(wildcard $(libpthread_DIR)/gen_*.c)) # 
dummy generated files
 libpthread-routines- += allocatestack.c # dummy included by pthread_create.c
 libpthread-routines- += pthread_mutex_getprioceiling.c 
pthread_mutex_setprioceiling.c # XXX: delete those or use them!
@@ -201,7 +202,7 @@ CFLAGS-msgsnd.c = -fexceptions -fasynchronous-unwind-tables
 CFLAGS-tcdrain.c = -fexceptions -fasynchronous-unwind-tables
 
 CFLAGS-pt-system.c = -fexceptions -I$(top_srcdir)libc/stdlib
-
+CFLAGS-pthread_atfork.c = -DNOT_IN_libc
 #
 # The rest of this file is uClibc specific.
 #
-- 
2.6.2

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

[PATCH 9/9] wire in syncfs

[Khem Raj]

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 include/unistd.h   |  2 +-
 libc/sysdeps/linux/common/syncfs.c | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 libc/sysdeps/linux/common/syncfs.c

diff --git a/include/unistd.h b/include/unistd.h
index 3793d2d..d01bb08 100644
--- a/include/unistd.h
+++ b/include/unistd.h
@@ -1073,7 +1073,7 @@ extern char *getpass (const char *__prompt) __nonnull 
((1));
 extern int fsync (int __fd);
 #endif /* Use BSD || X/Open || Unix98.  */
 
-#if 0 /*def __USE_GNU */
+#ifdef __USE_GNU
 /* Make all changes done to all files on the file system associated
  *with FD actually appear on disk.  */
 extern int syncfs (int __fd) __THROW;
diff --git a/libc/sysdeps/linux/common/syncfs.c 
b/libc/sysdeps/linux/common/syncfs.c
new file mode 100644
index 000..d2eed05
--- /dev/null
+++ b/libc/sysdeps/linux/common/syncfs.c
@@ -0,0 +1,13 @@
+/* vi: set sw=4 ts=4: */
+/*
+ * fsync() for uClibc
+ *
+ * Copyright (C) 2000-2006 Erik Andersen <ander...@uclibc.org>
+ *
+ * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
+ */
+
+#include 
+#include 
+
+_syscall1(int, syncfs, int, fd)
-- 
2.6.2

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

[PATCH 2/9] Add implementation for copysignl for ppc

[Khem Raj]

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 libc/sysdeps/linux/powerpc/Makefile.arch |  2 +-
 libc/sysdeps/linux/powerpc/copysignl.c   | 89 
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 libc/sysdeps/linux/powerpc/copysignl.c

diff --git a/libc/sysdeps/linux/powerpc/Makefile.arch 
b/libc/sysdeps/linux/powerpc/Makefile.arch
index 4fbcb11..7c09c87 100644
--- a/libc/sysdeps/linux/powerpc/Makefile.arch
+++ b/libc/sysdeps/linux/powerpc/Makefile.arch
@@ -5,7 +5,7 @@
 # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
 #
 
-CSRC-y := __syscall_error.c ioctl.c
+CSRC-y := __syscall_error.c ioctl.c copysignl.c
 
 SSRC-y := \
__longjmp.S setjmp.S bsd-setjmp.S bsd-_setjmp.S brk.S \
diff --git a/libc/sysdeps/linux/powerpc/copysignl.c 
b/libc/sysdeps/linux/powerpc/copysignl.c
new file mode 100644
index 000..000f653
--- /dev/null
+++ b/libc/sysdeps/linux/powerpc/copysignl.c
@@ -0,0 +1,89 @@
+/* s_copysignl.c -- long double version of s_copysign.c.
+ * Conversion to long double by Ulrich Drepper,
+ * Cygnus Support, drep...@cygnus.com.
+ */
+
+/*
+ * 
+ * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
+ *
+ * Developed at SunPro, a Sun Microsystems, Inc. business.
+ * Permission to use, copy, modify, and distribute this
+ * software is freely granted, provided that this notice
+ * is preserved.
+ * 
+ */
+
+/*
+ * copysignl(long double x, long double y)
+ * copysignl(x,y) returns a value with the magnitude of x and
+ * with the sign bit of y.
+ */
+
+#include 
+#include 
+
+#if __FLOAT_WORD_ORDER == BIG_ENDIAN
+
+typedef union
+{
+  long double value;
+  struct
+  {
+int sign_exponent:16;
+unsigned int empty:16;
+uint32_t msw;
+uint32_t lsw;
+  } parts;
+} ieee_long_double_shape_type;
+
+#endif
+
+#if __FLOAT_WORD_ORDER == LITTLE_ENDIAN
+
+typedef union
+{
+  long double value;
+  struct
+  {
+uint32_t lsw;
+uint32_t msw;
+int sign_exponent:16;
+unsigned int empty:16;
+  } parts;
+} ieee_long_double_shape_type;
+
+#endif
+
+/* Get int from the exponent of a long double.  */
+
+#define GET_LDOUBLE_EXP(exp,d) \
+do {   \
+  ieee_long_double_shape_type ge_u;\
+  ge_u.value = (d);\
+  (exp) = ge_u.parts.sign_exponent;\
+} while (0)
+
+/* Set exponent of a long double from an int.  */
+
+#define SET_LDOUBLE_EXP(d,exp) \
+do {   \
+  ieee_long_double_shape_type se_u;\
+  se_u.value = (d);\
+  se_u.parts.sign_exponent = (exp);\
+  (d) = se_u.value;\
+} while (0)
+
+long double copysignl(long double x, long double y);
+libc_hidden_proto(copysignl);
+
+long double copysignl(long double x, long double y)
+{
+   uint32_t es1,es2;
+   GET_LDOUBLE_EXP(es1,x);
+   GET_LDOUBLE_EXP(es2,y);
+   SET_LDOUBLE_EXP(x,(es1&0x7fff)|(es2&0x8000));
+return x;
+}
+
+libc_hidden_def(copysignl);
-- 
2.6.2

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

[PATCH 5/9] Always use -O2 for compiling fork.c

[Khem Raj]

When compiling in thumb mode for arm with -Os gcc gives up since it can
not find registers to spill. So we use -O2 option for compiling fork.c
It may be addressable in gcc.

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch 
b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch
index 0ea0b29..0767e9c 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/Makefile.arch
@@ -21,3 +21,9 @@ ASFLAGS-pt-vfork.S = -marm
 CFLAGS-OMIT-pt-vfork.S = -mthumb
 ASFLAGS-vfork.S = -marm
 CFLAGS-OMIT-vfork.S = -mthumb
+
+# For arm fork.c does not compile with -Os when compiling
+# in thumb1 mode
+ifeq ($(COMPILE_IN_THUMB_MODE),y)
+CFLAGS-fork.c = -O2
+endif
-- 
2.6.2

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

[PATCH 1/9] Disable lrount_tes() function

[Khem Raj]

Its not used anyway, avoids some strict compiler warnings

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 test/math/libm-test.inc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/test/math/libm-test.inc b/test/math/libm-test.inc
index f50b48b..6d70a95 100644
--- a/test/math/libm-test.inc
+++ b/test/math/libm-test.inc
@@ -3470,7 +3470,6 @@ logb_test (void)
 }
 
 
-#if 0
 static void
 lround_test (void)
 {
@@ -3605,7 +3604,6 @@ llround_test (void)
 
   END (llround);
 }
-#endif
 
 static void
 modf_test (void)
-- 
2.6.2

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

[PATCH 4/9] Dont support localised optimizations this helps to have a global -O level

[Khem Raj]

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 libpthread/nptl/pthread_mutex_timedlock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libpthread/nptl/pthread_mutex_timedlock.c 
b/libpthread/nptl/pthread_mutex_timedlock.c
index 04187f6..f56f6c5 100644
--- a/libpthread/nptl/pthread_mutex_timedlock.c
+++ b/libpthread/nptl/pthread_mutex_timedlock.c
@@ -28,7 +28,9 @@
  * error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’
  */
 int
+#ifndef  __OPTIMIZE__
 attribute_optimize("Os")
+#endif
 pthread_mutex_timedlock (
  pthread_mutex_t *mutex,
  const struct timespec *abstime)
-- 
2.6.2

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

[PATCH 10/10] gcc5 optimizes away the write only static functions and we end up with

[Khem Raj]

  librt/librt_so.a(rt-unwind-resume.oS): In function `_Unwind_Resume':
  rt-unwind-resume.c:(.text+0x3c): undefined reference to `libgcc_s_resume'
  collect2: error: ld returned 1 exit status
  make[2]: *** [lib/librt.so] Error 1

marking these functions explicitly used with __attribute_used__ avoids
that optimization.

Signed-off-by: Khem Raj <raj.k...@gmail.com>
---
 libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c | 2 +-
 libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c 
b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c
index f4d6f41..0c2edd7 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c
@@ -27,7 +27,7 @@
 #define __libc_fatal(x) {/*write(STDERR_FILENO, x, strlen(x));*/ 
abort();}
 
 static void *libgcc_s_handle;
-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc);
+static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) 
__attribute_used__;
 static _Unwind_Reason_Code (*libgcc_s_personality)
   (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *);
 static _Unwind_Reason_Code (*libgcc_s_forcedunwind)
diff --git a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c 
b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c
index f9a4ffb..f0c3047 100644
--- a/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c
+++ b/libpthread/nptl/sysdeps/unix/sysv/linux/arm/unwind-resume.c
@@ -25,7 +25,7 @@
 #define __libc_dlclose  dlclose
 #define __libc_fatal(x) {/*write(STDERR_FILENO, x, strlen(x));*/ 
abort();}
 
-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc);
+static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) 
__attribute_used__;
 static _Unwind_Reason_Code (*libgcc_s_personality)
   (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *);
 
-- 
2.6.2

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

Re: libutil's logout doesn't clear utmp entries

[Khem Raj]

 On Aug 17, 2015, at 1:29 PM, Ata, John (US) john@baesystems.com wrote:
 
 Hi,
 
 The module logout() in libutil does not actually remove the utmp entry that 
 it attempts to do.  This is because it uses getutline() to read the utmp 
 entry which is returned in utmp's internal static buffer.  It then modifies 
 the static entry directly and attempts to write it out with pututline().  
 However, pututline() reads the original entry before writing it into the 
 internal static buffer (only one internal utmp buffer) so it then always 
 writes the original unchanged record back out.  One fix is to copy the static 
 buffer into the temporary tmp stack variable (no longer needed) after reading 
 but before writing.  This has been tested and appears to work well.
 
 +--- uclibc/libutil/logout.c2012-05-15 03:20:09.0 -0400
  uclibc/libutil/logout.c2015-08-14 16:59:06.625944541 -0400
 +@@ -45,6 +45,10 @@
 +   /* Read the record.  */
 +   if ((ut = getutline(tmp)) != NULL)

would it help if getutline was thread safe.

 + {
 ++  /* We can't use the utmp static buffer on the rewrite so copy over */
 ++  memcpy(tmp, ut, sizeof tmp);
 ++  ut = tmp;
 ++
 +   /* Clear information about who  from where.  */
 +   memset (ut-ut_name, 0, sizeof ut-ut_name);
 + #if _HAVE_UT_HOST - 0
 
 --
 John Ata
 BAE Systems
 STOP Software Development
 
 ___
 uClibc mailing list
 uClibc@uclibc.org
 http://lists.busybox.net/mailman/listinfo/uclibc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Question: Does uclibc support NPTL TLS ?

[Khem Raj]

 On May 27, 2015, at 6:21 PM, Sheng Yong shengyo...@huawei.com wrote:
 
 Hi,
 
 On 5/28/2015 3:18 AM, Rich Felker wrote:
 On Wed, May 27, 2015 at 05:10:53PM +0800, Sheng Yong wrote:
 Hi,
 
 I encountered a problem when I test thread local storage
 on my arm board (kernel 3.10.77 and uclibc 0.99.3.2).
 
 Please let me know if I am doing something wrong for
 debugging TLS.
 
 on my x86 host machine:
 root@kernel-host:~ cat tls.c
 __thread int i =5;
 
 int
 main (int argc, char **argv)
 {
  return 0;
 }
 
 root@kernel-host:~ arm-linux-uclibceabi-gcc -o tls tls.c -g -lpthread
 
 If you add output (printf(%d, i)) to the program and actually run
 it, does it work? It looks to me like the failure you're observing is
 the inability of gdb to find the TLS while debugging, which is
 separate from whether TLS is supported.
 I test it, it can printf the value of `i'. I don't know if there are any 
 options
 that impact on gcc or gdb. I checked the configure log and compile log, there 
 is
 no optins `-disable-tls' or `-no-tls' or the like.
 
 $ cat tls.c
 #include stdio.h
 
 __thread int i =5;
 
 int
 main (int argc, char **argv)
 {
   printf(%d\n, i);
   return 0;
 }
 
 sh-4.2# ./tls
 5
 

Seems like gdb is not able to comprehend the TLS structure that uclibc is 
putting. So you need to investigate
that part, either gdb or libthread-db may be where the issue lies.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 06/12] do not depend on compile

[Khem Raj]

On 14-08-27 08:01:43, Waldemar Brodkorb wrote:
 When you cross-compile the testsuite and then try to run
 on a system without gcc/binutils it would be nice if no compiling
 or linking is tried.

This would also need changes to test/README to reflect this change

 
 Signed-off-by: Waldemar Brodkorb w...@openadk.org
 ---
  test/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/test/Makefile b/test/Makefile
 index b759bf9..787c530 100644
 --- a/test/Makefile
 +++ b/test/Makefile
 @@ -45,7 +45,7 @@ endif
  
  test check all: run
  
 -run: compile subdirs_run
 +run: subdirs_run
  
  compile: $(top_builddir)$(LOCAL_INSTALL_PATH) subdirs_compile
  
 -- 
 1.8.5.2 (Apple Git-48)
 
 ___
 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

Re: sorry for duplicate mails

[Khem Raj]

On 14-08-27 08:05:24, Waldemar Brodkorb wrote:
 Hi,
 
 I refreshed my patchset with Sob Line w...@openadk.org and forgot to
 delete the old set in my outgoing dir. Sorry for the duplicate
 mails.

Thanks, looks good, I have provided feedback 
 
 Will publish test suite results soon.
 
 best regards
  Waldemar
 
 ___
 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

Re: Question - intention of UCLIBC_BUILD_NOEXECSTACK?

[Khem Raj]

On 14-08-26 21:35:57, Bernhard Reutner-Fischer wrote:
 On 25 August 2014 15:57, Andrew McDonnell b...@andrewmcdonnell.net wrote:
  On 25/08/14 22:56, Andrew McDonnell wrote:
  Hmmm, I am having some trouble repeating my original result.
 
  snipped
 
  OK, with a fresh build, the following appears to apply:
 
  * OpenWRT sets UCLIBC_BUILD_NOEXECSTACK=y
 
  * Somehow this ends up with libcrypt, libm, libresolv, libnsl, libthread_db,
  libdl and  and libutil actually having the NX flag set in the ELF despite
  there being no -Wl,-z,noexecstack linker option specified.
 
  This I really do not understand yet!
 
  * ld-uClibc, librt, libuClibc and libpthread _dont have the NX flag set, 
  which
  is what I would have expected when the link was missing the noexecstack 
  option.
 
  * The above was checked before any stripping applied, just in case
 
  Now its gotten too late, so I'll have to re-test my patch that applies the
  noexecstack marking to ld-uClibc, librt, libuClibc and libpthread as well
  later this week before I submit it.
 
  FWIW this is all done using the OpenWRT buildroot for a carambola2 target
 
  There is another oddity with all of this, as well.
 
  Every single one of libcrypt, libm, libresolv, libnsl, libthread_db, libdl,
  libutil, libuClibc, librt and libpthread are all built with -Wl,-z-relro yet
  the GNU_RELRO section is only present in libdl, libpthread and libuClibc and
  yet all are built with exactly the same set of -Wl,-z options
 
  I am wondering if this is this bug,
  https://sourceware.org/bugzilla/show_bug.cgi?id=16322 because OpenWRT 
  binutils
  is still 2.23
 
 I cannot reproduce this with binutils-gdb 2.24.51.20140818.
 Can you try with binutils 2.24 or later please?

Are you trying OE binutils ? we have backported a patch into it for
textrels

 
 TIA,
 ___
 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

[PATCH 2/2] timex: Sync with glibc

[Khem Raj]

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 include/sys/timex.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/sys/timex.h b/include/sys/timex.h
index 9082a28..57059bd 100644
--- a/include/sys/timex.h
+++ b/include/sys/timex.h
@@ -67,8 +67,12 @@ struct timex
 #define ADJ_ESTERROR   0x0008  /* estimated time error */
 #define ADJ_STATUS 0x0010  /* clock status */
 #define ADJ_TIMECONST  0x0020  /* pll time constant */
-#define ADJ_TICK   0x4000  /* tick value */
-#define ADJ_OFFSET_SINGLESHOT  0x8001  /* old-fashioned adjtime */
+#define ADJ_TAI0x0080  /* set TAI offset */
+#define ADJ_MICRO  0x1000  /* select microsecond resolution */
+#define ADJ_NANO   0x2000  /* select nanosecond resolution */
+#define ADJ_TICK   0x4000  /* tick value */
+#define ADJ_OFFSET_SINGLESHOT  0x8001  /* old-fashioned adjtime */
+#define ADJ_OFFSET_SS_READ 0xa001  /* read-only adjtime */
 
 /* xntp 3.4 compatibility names */
 #define MOD_OFFSET ADJ_OFFSET
-- 
2.1.0

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

[PATCH 1/2] Define IPTOS_CLASS_* macros according to RFC 2474

[Khem Raj]

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 include/netinet/ip.h | 42 ++
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/include/netinet/ip.h b/include/netinet/ip.h
index 19e1249..3fe58b9 100644
--- a/include/netinet/ip.h
+++ b/include/netinet/ip.h
@@ -188,7 +188,25 @@ struct ip_timestamp
 #defineIPTOS_DSCP_EF   0xb8
 
 /*
- * Definitions for IP type of service (ip_tos)
+ * In RFC 2474, Section 4.2.2.1, the Class Selector Codepoints subsume
+ * the old ToS Precedence values.
+ */
+#defineIPTOS_CLASS_MASK0xe0
+#defineIPTOS_CLASS(class)  ((class)  IPTOS_CLASS_MASK)
+#defineIPTOS_CLASS_CS0 0x00
+#defineIPTOS_CLASS_CS1 0x20
+#defineIPTOS_CLASS_CS2 0x40
+#defineIPTOS_CLASS_CS3 0x60
+#defineIPTOS_CLASS_CS4 0x80
+#defineIPTOS_CLASS_CS5 0xa0
+#defineIPTOS_CLASS_CS6 0xc0
+#defineIPTOS_CLASS_CS7 0xe0
+
+#defineIPTOS_CLASS_DEFAULT IPTOS_CLASS_CS0
+
+/*
+ * Definitions for IP type of service (ip_tos) [deprecated; use DSCP
+ * and CS definitions above instead.]
  */
 #defineIPTOS_TOS_MASK  0x1E
 #defineIPTOS_TOS(tos)  ((tos)  IPTOS_TOS_MASK)
@@ -199,18 +217,18 @@ struct ip_timestamp
 #defineIPTOS_MINCOST   IPTOS_LOWCOST
 
 /*
- * Definitions for IP precedence (also in ip_tos) (hopefully unused)
+ * Definitions for IP precedence (also in ip_tos) [also deprecated.]
  */
-#defineIPTOS_PREC_MASK 0xe0
-#defineIPTOS_PREC(tos)((tos)  IPTOS_PREC_MASK)
-#defineIPTOS_PREC_NETCONTROL   0xe0
-#defineIPTOS_PREC_INTERNETCONTROL  0xc0
-#defineIPTOS_PREC_CRITIC_ECP   0xa0
-#defineIPTOS_PREC_FLASHOVERRIDE0x80
-#defineIPTOS_PREC_FLASH0x60
-#defineIPTOS_PREC_IMMEDIATE0x40
-#defineIPTOS_PREC_PRIORITY 0x20
-#defineIPTOS_PREC_ROUTINE  0x00
+#defineIPTOS_PREC_MASK IPTOS_CLASS_MASK
+#defineIPTOS_PREC(tos) IPTOS_CLASS(tos)
+#defineIPTOS_PREC_NETCONTROL   IPTOS_CLASS_CS7
+#defineIPTOS_PREC_INTERNETCONTROL  IPTOS_CLASS_CS6
+#defineIPTOS_PREC_CRITIC_ECP   IPTOS_CLASS_CS5
+#defineIPTOS_PREC_FLASHOVERRIDEIPTOS_CLASS_CS4
+#defineIPTOS_PREC_FLASHIPTOS_CLASS_CS3
+#defineIPTOS_PREC_IMMEDIATEIPTOS_CLASS_CS2
+#defineIPTOS_PREC_PRIORITY IPTOS_CLASS_CS1
+#defineIPTOS_PREC_ROUTINE  IPTOS_CLASS_CS0
 
 /*
  * Definitions for options.
-- 
2.1.0

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

Re: Question - intention of UCLIBC_BUILD_NOEXECSTACK?

[Khem Raj]

On 14-08-25 12:06:16, b...@andrewmcdonnell.net wrote:
 Hi,
 
 I have been playing with uClibc on some embedded Linux systems, and trying
 out some hardening techniques.
 
 When I tested the .so files built by uClibc (using the checksec.sh tool from
 http://www.trapkit.de/tools/checksec.html, which is basically a wrapper
 around readelf), the files do not exhibit the GNU_STACK flag.
 
 What I would like to do is actually build with the linker option
 '-Wl,-z,noexecstack' as per
 http://www.win.tue.nl/~aeb/linux/hh/protection.html or
 http://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart (for just two
 examples)  I eventually managed to do this by using and patching Config.in
 (0.9.33.2) to recognise UCLIBC_LDFLAGS_EXTRA , after which the .so files had
 the relevant flag. (I can post that patch to enable UCLIBC_LDFLAGS_EXTRA
 separately)
 
 One thing I noticed is that uClibc has a Config setting
 UCLIBC_BUILD_NOEXECSTACK but all this seems to do is pass the relevant flag
 to the assembler and not to the linker. The gentoo hardening guide applies
 the flag to both assembler and linker stage.
 
 According to Config.in help: Mark all assembler files as noexecstack. This
 will result in marking
 all libraries and executables built against uClibc not requiring
 executable stack.
 
 I guess the gap in my knowledge is how uClibc, by only applying to assembler
 files, meets marking all libraries and executables when the GNU_STACK flag
 is missing from the ELF images? Note it has been a very long time since I

it wont. Can you patch UCLIBC_BUILD_NOEXECSTACK code to pass the linker
option as well ?

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

Re: Question - intention of UCLIBC_BUILD_NOEXECSTACK?

[Khem Raj]

On 14-08-25 15:41:17, b...@andrewmcdonnell.net wrote:
 On 2014-08-25 15:17, Khem Raj wrote:
 On 14-08-25 12:06:16, b...@andrewmcdonnell.net wrote:
 
 snipped
 
 
 I guess the gap in my knowledge is how uClibc, by only applying to
 assembler
 files, meets marking all libraries and executables when the GNU_STACK
 flag
 is missing from the ELF images? Note it has been a very long time since
 I
 
 it wont. Can you patch UCLIBC_BUILD_NOEXECSTACK code to pass the linker
 option as well ?
 
 Yes, I did, that was how I confirmed the UCLIBC_BUILD_NOEXECSTACK option
 seems to be ambiguously named.
 
 I have two alternative patches: either
 (a) a patch that adds a new option UCLIBC_BUILD_NOEXECSTACK_ALL, to retain
 meaning and backward compatibility of the existing config option,
 (b) a patch that updates UCLIBC_BUILD_NOEXECSTACK to apply at the linker
 stage

(b) is what we need.

 
 I guess I was trying to find out if there was a reason things are the way
 they are, prior to submitting one of my patches.
 
 --Andrew
 
 ---
 
 http://blog.oldcomputerjunk.net
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: hashcode handling

[Khem Raj]

On Fri, Jul 25, 2014 at 9:10 AM, czankel ch...@zankel.net wrote:
 Hi,

 The following patches are still outstanding since Nov '13. It would be great
 if someone could approve them or give feedback. These generic changes are
 required to add NPTL support for Xtensa.

 http://patchwork.ozlabs.org/patch/288804/
 http://patchwork.ozlabs.org/patch/288805/

both look ok to me.


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

Re: [OpenWrt-Devel] uClibc-ng

[Khem Raj]

On Thu, Jul 24, 2014 at 1:48 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 On Wed, Jul 23, 2014 at 09:20:51PM +0200, Carmelo Amoroso wrote:


 Il 23 luglio 2014 13:42:38 Jody Bruchon j...@jodybruchon.com ha scritto:

 On 7/22/2014 11:30 PM, Steve Bennett wrote: I would like to add my
 support to Thomas' position.
   Regardless of what happens with glibc and/or musl, an active community
   supporting regular releases of uClibc is a good thing.
   Time has spoken that we can't expect this to happen unless something
 changes.
 
 I agree. It is better to have a responsive maintainer releasing periodic
 stable versions than to have what is essentially no maintainer and
 sustained long-term fragmentation of what uClibc really is. If the
 uClibc maintainer wakes up in the future and begins releasing again, the
 new project's changes can always be merged back to the parent, as they
 did with eglibc and glibc. For now we need to focus on making a stable
 release, something which is grossly overdue and harms all projects
 currently using uClibc.
 
 I also agree that musl is an interesting project with a bright future
 (and a bright present for that matter), but it does not cover all of
 what uClibc covers and the number of projects that already require
 uClibc is too large to simply drop uClibc and move to musl.
 
 -Jody Bruchon

 Gents,
 Are we considering anyway that Bernard has recently restarted with patches
 review and commit without no contribution from the other co-maintainers
 (myself the first) ?
 Likely Bernard is already preparing a release !

 Yea, but very very slowly, i know.
 I just started preparing a meta-changelog for the release notes and
 then we'll call it an official tarball.

 Lots of changes, about 10% done, approx. 1h left before bedtime.

 Any prominent changes we should make absolutely sure to mention?

I think

ARC support would be one.
standalone execution on x86_64 now works
math tests are fixed
MIPS64R2 support is added




 ___
 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

Re: Switching from uClibc to glibc as the default in Buildroot?

[Khem Raj]

Hi Thomas

On Tue, Feb 18, 2014 at 2:14 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
 Hello,

 The uClibc project has not released any new version since almost two
 years, despite the fact that there are numerous known issues and
 limitations in 0.9.33.2, and a good set of fixes in the 0.9.33 branch
 that have never been part of any release.

 This lack of stable releases is causing major issues for build systems
 such as Buildroot. Not only do we have to carry a large number of
 backported patches to fix uClibc bugs and add missing system calls and
 functionalities needed to run modern software, but we also have issues
 supporting uClibc toolchains provided by other parties (such as
 processor vendors), because they are not using the same set of
 backported patches. The lack of releases is causing fragmentation
 between the various uClibc versions, making uClibc more and more
 painful to support in Buildroot.

 To give you an idea, Buildroot currently has more than 50 patches on
 top of uClibc 0.9.33.2:

   http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2/

Indeed, I see what you are saying here. In order to begin the process,
can you send a list of patches
that buildroot is carrying for inclusion into master. Secondly, would
it be just fine if the release is made
in form of a git branch and no tarballs? regardless I would request
all to send/resend the patches that are for master so we can
collect them on patchwork here

http://patchwork.ozlabs.org/project/uclibc/list/

and process can begin.


 OpenEmbedded has to use a Git version of uClibc, with a few patches:


given the patches and development activity we snapshot uclibc trunk
and that works out ok.

   
 https://github.com/openembedded/oe-core/blob/master/meta/recipes-core/uclibc/uclibc-git.inc

 OpenWRT also has a good number of patches:

   https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.33.2

 We have already asked for stable releases in September 2013 [1], then
 in November 2013 [2], and finally in December 2013 [3], and still no
 release has been made.

 Historically, Buildroot was created as a tool to generate small Linux
 systems based on uClibc, in order to test and exercise uClibc. Since
 its origin, Buildroot has had uClibc as its default C library, quite
 certainly helping in propagating uClibc in embedded Linux systems.

 However, due to the reasons mentioned above, supporting uClibc has
 proven to be more and more complicated. Therefore, at the latest
 Buildroot Developers Meeting, we discussed the idea of switching to
 using glibc as the default C library in Buildroot for the
 architectures that glibc supports.

 But before doing that, we would like to discuss this problem again
 with the uClibc community, and see if something can be done to revive
 the project in terms of delivering releases. Adopting a time-based
 release schedule has proven to work really well for Buildroot, and we
 believe this solution should be considered by the uClibc developers.

 Thanks!

 Thomas, on behalf of the Buildroot core developers: Peter Korsgaard,
 Yann E. Morin, Samuel Martin, Thomas De Schampheleire.

 [1] http://lists.uclibc.org/pipermail/uclibc/2013-September/047942.html
 [2] http://lists.uclibc.org/pipermail/uclibc/2013-November/048029.html
 [3] http://lists.uclibc.org/pipermail/uclibc/2013-December/048102.html
 --
 Thomas Petazzoni, CTO, Free Electrons
 Embedded Linux, Kernel and Android engineering
 http://free-electrons.com
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Switching from uClibc to glibc as the default in Buildroot?

[Khem Raj]

On Feb 18, 2014, at 5:46 PM, Jody Lee Bruchon j...@jodybruchon.com wrote:

 On February 18, 2014 7:23:11 PM EST, Khem Raj raj.k...@gmail.com wrote:
 inclusion into master. Secondly, would
 it be just fine if the release is made
 in form of a git branch and no tarballs?
 
 I would like to point out that the last release of uClibc with a version 
 number was released 2012-05-15.

there is no need to state the obvious.

 This is a 21-month gap since the last release, which usually leads people to 
 believe that the project is stagnating or no longer maintained (which it may 
 have been, since there were no Git commits in 2013 save for a few in early 
 January.) It also forces anyone trying to release to come up with their own 
 way to handle versioning.
 
 There are a great number of fixes since the last numbered release and I for 
 one would greatly appreciate having at least a testing release with a 
 bumped version number to use. Other than the ldso stat call problem I 
 reported a couple of weeks ago, uClibc trunk has been working fairly well, 
 and most bugs I run into are the typical growing pains of toolchain building 
 from scratch rather than uClibc problems.

so get going start testing git/master and report issues or successes you have.
help in testing it out, run uclibc test suites or any others you have setups for

 
 I don't think that a Git release is appropriate for these reasons. Besides, 
 if you did tag a Git commit with a version number, there's also no reason not 
 to put out a tarball to go with it, right?

it needs some work whereas with git you can download the tars from cgit, but 
not a big issue. We can release tar balls too.

 
 -Jody Bruchon

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

Re: [PATCH] Fix sync_file_range.c for MIPS64 N32 ABI builds.

[Khem Raj]

On Feb 12, 2014, at 10:09 AM, Steve Ellcey sell...@mips.com wrote:

 The special sync_file_range handling is only needed for the O32 ABI
 (regardless of whether it is on mips32 or mips64).  The N32 (and N64)
 ABI's should both use the standard code.  This routine was using the
 special code for the N32 ABI because that ABI has a word size of 32 bits
 and that is wrong.  This patch fixes it by checking the ABI used instead
 of checking the word size.
 
 Signed-off-by: Steve Ellcey sell...@mips.com
 ---
 libc/sysdeps/linux/common/sync_file_range.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libc/sysdeps/linux/common/sync_file_range.c 
 b/libc/sysdeps/linux/common/sync_file_range.c
 index 66751c6..8d4ed92 100644
 --- a/libc/sysdeps/linux/common/sync_file_range.c
 +++ b/libc/sysdeps/linux/common/sync_file_range.c
 @@ -24,7 +24,7 @@ static int __NC(sync_file_range)(int fd, off64_t offset, 
 off64_t nbytes, unsigne
 {
 #  if defined __powerpc__  __WORDSIZE == 64
   return INLINE_SYSCALL(sync_file_range, 4, fd, offset, nbytes, flags);
 -#  elif defined __mips__  __WORDSIZE == 32
 +#  elif defined __mips__  _MIPS_SIM == _ABIO32
   return INLINE_SYSCALL(sync_file_range, 7, fd, 0,
   OFF64_HI_LO(offset), OFF64_HI_LO(nbytes), flags);

This looks good to me.


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

Re: MIPS64 N64 SIGBUS error

[Khem Raj]

On Tue, Nov 26, 2013 at 11:17 AM, Waldemar Brodkorb w...@openadk.org wrote:
 Hi Bernhard,
 Bernhard Reutner-Fischer wrote,

 On 24 November 2013 10:51, Waldemar Brodkorb w...@openadk.org wrote:
  Hi Developers,
 
  I am trying to find the reason for a SIGBUS error, when

 which binutils? ld.gold or bfd?
 thanks,

 Binutils 2.23.2. normal ld not ld.gold.
 I have done a deeper look into glibc 2.18 code and found out that
 they are using ElfW(Addr) for the relocation address (or negative
 offset?), see ./ports/sysdeps/mips/dl-machine.h.

 After changing this, the SIGBUS is gone.
 I have done following change to fix the debug output, too:

 diff -Nur uClibc-dev.orig/ldso/ldso/mips/elfinterp.c 
 uClibc-dev/ldso/ldso/mips/elfinterp.c
 --- uClibc-dev.orig/ldso/ldso/mips/elfinterp.c  2013-11-23 22:51:50.0 
 +0100
 +++ uClibc-dev/ldso/ldso/mips/elfinterp.c   2013-11-25 11:46:04.0 
 +0100
 @@ -259,11 +259,11 @@
 case R_MIPS_TLS_TPREL32:
 case R_MIPS_TLS_TPREL64:
 CHECK_STATIC_TLS((struct 
 link_map *)tls_tpnt);
 -   *(ElfW(Word) *)reloc_addr +=
 +   *(ElfW(Addr) *)reloc_addr +=
 TLS_TPREL_VALUE 
 (tls_tpnt, symbol_addr);
  #ifdef __SUPPORT_LD_DEBUG__
 _dl_dprintf(2, TLS_TPREL  : 
 %s, %x, %x\n,
 -   symname, old_val, 
 *((unsigned int *)reloc_addr));
 +   symname, old_val, 
 *((unsigned long *)reloc_addr));
  #endif
 break;
 }

 What do you think about this change?

this looks ok can you submit a properly formatted patch please ?

I verified that it does not
 effect a mips32 o32 build.

 Thanks for any comments.
  Waldemar
 ___
 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

Re: Doing a release?

[Khem Raj]

On Wednesday, November 6, 2013, Thomas Petazzoni wrote:

 Hello,

 On Wed, 18 Sep 2013 06:49:44 +0200, Thomas Petazzoni wrote:
  Dear uClibc developers,
 
  The last release of uClibc, 0.9.33.2, has been made well over a year
  ago. However, there is fairly big number of improvements/fixes in the
  master branch that would be interesting to have in a release. At the
  Buildroot level, we now have 53 patches in your patch stack against
  uClibc 0.9.33.2, all coming from the master branch if I'm correct (see
  http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2).
 
  It'd be really nice if uClibc adopted a slightly more frequent release
  schedule, to more easily allow downstream users to benefit from
  improvements/fixes.

 Approximately 1.5 months after my initial e-mail, nothing seems to have
 happened on the front of getting a release out.

 Would it be possible to take the current master, and release it as
 0.9.34-rc1 maybe, so we can integrate it in Buildroot for example, give
 it a little bit of testing, and hopefully have a 0.9.34 release soon
 after that?

 I've seen both the ARC port (from Vineet) and the Xtensa NPTL support
 (from Chris), but I don't think the uClibc community should wait
 indefinitely for more and more features to show up and get merged
 before doing a release. Let's release 0.9.34 with the current feature
 set, and plan a 0.9.35 release not too late after that with the ARC
 port and Xtensa NPTL support added, for example.


i have been preparing setup to test the outstanding patches which now i have
i think most of the changes arent affecting core as much so can vbe tried
for the release

Thanks,

 Thomas
 --
 Thomas Petazzoni, CTO, Free Electrons
 Embedded Linux, Kernel and Android engineering
 http://free-electrons.com
 ___
 uClibc mailing list
 uClibc@uclibc.org javascript:;
 http://lists.busybox.net/mailman/listinfo/uclibc

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

Re: Doing a release?

[Khem Raj]

On Nov 6, 2013, at 11:23 AM, czankel ch...@zankel.net wrote:

 Hi Khem,
 
 On 11/6/13 11:05 AM, Khem Raj wrote:
 On Wednesday, November 6, 2013, Thomas Petazzoni wrote:
 
 i have been preparing setup to test the outstanding patches which now i have
 i think most of the changes arent affecting core as much so can vbe tried
 for the release
 Do you have a list of those changes? I have seen a lot floating around, so 
 would be good to see that you have all of them. Also, on what HW are you 
 testing uClibc?

here is a list its not complete
http://patchwork.ozlabs.org/project/uclibc/list/

 
 Thanks,
 -Chris
 ___
 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

Re: Adding support for TLS/NPTL for Xtensa

[Khem Raj]

On Thursday, October 31, 2013, Chris Zankel wrote:

 Hi,

 Baruch Siach and I have been working on supporting TLS and NPTL for the
 Xtensa architecture, and I would like to start committing those changes.

 Most changes are very limited to the Xtensa architecture, so shouldn't
 affect other architectures at all. However, the Xtensa implementation
 requires TLS descriptor support, which Baruch has ported to uClibc, and it
 touches shared code. We'll post that patch for review.

 I understand that there have been requests for a next release, and it
 would be great if we could get NPTL support for Xtensa into that release.
 Some library functions are only implemented in NPTL and not the old
 linuxthreads library, so I see failures when building some packages with
 buildroot.


while we have not deprecated lt.old it would be better that we do not
regress it otherwise if the patch to shared code is managable it should not
be a big problem
i would also suggest to build and regress some other architectures with
nptl to have confidence in the patch



 Please let me know if you have any objects or suggestions.

 Thanks,
 -Chris






 __**_
 uClibc mailing list
 uClibc@uclibc.org
 http://lists.busybox.net/**mailman/listinfo/uclibchttp://lists.busybox.net/mailman/listinfo/uclibc

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

Re: Building uclibc for big-endian and little-endian target.

[Khem Raj]

Hi Steve

On Oct 15, 2013, at 10:30 AM, Steve Ellcey sell...@mips.com wrote:

 I have a question about endiness and uclibc.  I am trying to build
 multiple versions of uclibc for MIPS, including big and little endian
 versions.  What I notice is that in Rules.mak there are lines:
 
 CPU_LDFLAGS-$(ARCH_LITTLE_ENDIAN) += -Wl,-EL
 CPU_LDFLAGS-$(ARCH_BIG_ENDIAN)+= -Wl,-EB
 
 to add -EL or -EB to linker commands (this seems to be generic for all
 architectures).
 
 What I do not see is any generic (or MIPS specific) code to add -EL or -EB
 to CPU_CFLAGS (or CPU_FLAGS-y to be exact).  I am wondering if there is a
 specific reason for this?  Right now the uclibc build seems to assume that
 the compiler I am using to build uclibc will always generate the correct
 endiness without any flags.

That was consensus we had some time ago. Otherwise these flags were getting too 
many
and difficult to deal with.

  I want to build big and little endian uclibc's
 using a single cross compiler that is capable of generating both big and
 little endian objects given a -EL or a -EB.
 
 I know I can work around this by adding -EL or -EB to UCLIBC_EXTRA_CFLAGS
 when building but I am wondering why Rules.mak doesn't have:
 
 CPU_CFLAGS-$(ARCH_LITTLE_ENDIAN) += -EL
 CPU_CFLAGS-$(ARCH_BIG_ENDIAN)+= -EB
 
 If not for all CPU's, at least for MIPS and other bi-endian architectures.

As you pointed its specific to certain CPUs.

 
 How do other architectures handle building multiple uclibc libraries with
 different endiness settings?

Configure the toolchain and if you want additional tweaks then pass them via
UCLIBC_EXTRA_CFLAGS


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

Re: [PATCH-0.9.33] common/pread_write.c: unbreak on archs without __NR_pread64

[Khem Raj]

On Oct 15, 2013, at 1:41 PM, Peter Korsgaard pe...@korsgaard.com wrote:

 Mike == Mike Frysinger vap...@gentoo.org writes:
 
 Hi,
 
 The code nicely checks for it, but then ends up hard coding the syscall
 to use __NR_pread64 afterwards, rendering the check useless. Fix it by
 using the result of the test instead.
 
 Mike i think you should look at all the pread/pwrite changes in
 Mike master.  afaik, all issues are addressed there.
 
 Yes, possible. I'm trying to test the 0.9.33 branch to hopefully speed
 up the 0.9.33.3 release as there's quite some fixes pending, but it
 looks like some more stuff should get backported.
 
 Anybody else testing the branch?

I would be interested if you try out latest master.


 
 -- 
 Bye, Peter Korsgaard
 ___
 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

[PATCH] add posix_fadvise() for arm

[Khem Raj]

arm call to posix_fadvise simply calls posix_fadvise64

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 libc/sysdeps/linux/common/posix_fadvise.c |   24 
 1 file changed, 16 insertions(+), 8 deletions(-)

Upstream-Status: Pending

diff --git a/libc/sysdeps/linux/common/posix_fadvise.c 
b/libc/sysdeps/linux/common/posix_fadvise.c
index d3e1bd4..e102ce7 100644
--- a/libc/sysdeps/linux/common/posix_fadvise.c
+++ b/libc/sysdeps/linux/common/posix_fadvise.c
@@ -10,30 +10,38 @@
 
 #include sys/syscall.h
 
-#ifdef __NR_fadvise64
+#if defined(__NR_fadvise64) || defined(__NR_arm_fadvise64_64)
 # include fcntl.h
 # include endian.h
 # include bits/wordsize.h
 
+# ifdef __NR_arm_fadvise64_64
+int posix_fadvise64(int fd, off64_t offset, off64_t len, int advice);
+# endif
+
 int posix_fadvise(int fd, off_t offset, off_t len, int advice)
 {
+# ifdef __NR_arm_fadvise64_64
+   return posix_fadvise64(fd, offset, len, advice);
+# else
int ret;
INTERNAL_SYSCALL_DECL(err);
-# if __WORDSIZE == 64
+#  if __WORDSIZE == 64
ret = INTERNAL_SYSCALL(fadvise64, err, 4, fd, offset, len, advice);
-# else
-#  if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
-   ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
 #  else
+#   if defined(__UCLIBC_SYSCALL_ALIGN_64BIT__)
+   ret = INTERNAL_SYSCALL(fadvise64, err, 6, fd, /*unused*/0,
+#   else
ret = INTERNAL_SYSCALL(fadvise64, err, 5, fd,
-#  endif
+#   endif
OFF_HI_LO (offset), len, advice);
-# endif
+#  endif
if (INTERNAL_SYSCALL_ERROR_P (ret, err))
return INTERNAL_SYSCALL_ERRNO (ret, err);
return 0;
+#  endif
 }
-# if defined __UCLIBC_HAS_LFS__  (!defined __NR_fadvise64_64 || __WORDSIZE 
== 64)
+# if defined __UCLIBC_HAS_LFS__  ((!defined __NR_fadvise64_64  !defined 
__NR_arm_fadvise64_64) || __WORDSIZE == 64)
 strong_alias(posix_fadvise,posix_fadvise64)
 # endif
 #endif
-- 
1.7.9.5

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

Patchwork now available for uclibc

[Khem Raj]

Hi All,

ozlabs has kindly added uclibc project mailing list to tracked lists for 
patches, so we will be able to monitor/process
the patches on ozlabs patchwork instance here

http://patchwork.ozlabs.org/project/uclibc/list/

Right now, I am taking care of keeping it uptodate, and expect more  devs to 
start using it
Please use patchwork for tracking the patches

Happy patchworking

-Khem



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

Re: Doing a release?

[Khem Raj]

On Sep 17, 2013, at 9:49 PM, Thomas Petazzoni 
thomas.petazz...@free-electrons.com wrote:

 Dear uClibc developers,
 
 The last release of uClibc, 0.9.33.2, has been made well over a year
 ago. However, there is fairly big number of improvements/fixes in the
 master branch that would be interesting to have in a release. At the
 Buildroot level, we now have 53 patches in your patch stack against
 uClibc 0.9.33.2, all coming from the master branch if I'm correct (see
 http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2).
 
 It'd be really nice if uClibc adopted a slightly more frequent release
 schedule, to more easily allow downstream users to benefit from
 improvements/fixes.

I think, if we decide to do releases biannually maintaining branches for long 
time
can be avoided. To get started I think lets start by planning for a 0.9.34 and 
then
everyone sending the pending patches for subsequent 0.9.35 and so on.

 
 Thanks a lot!
 
 Thomas
 -- 
 Thomas Petazzoni, Free Electrons
 Kernel, drivers, real-time and embedded Linux
 development, consulting, training and support.
 http://free-electrons.com
 ___
 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

Re: [PATCH] Revert parser_config.[ch]: remove duplicated hidden functions

[Khem Raj]

On May 8, 2013, at 10:55 AM, Rich Felker dal...@aerifal.cx wrote:

 On Mon, May 06, 2013 at 09:32:57PM -0700, Khem Raj wrote:
 
 On May 6, 2013, at 9:10 PM, Vineet Gupta vineet.gup...@synopsys.com wrote:
 
 This attribute_hidden should not be resurrected.
 
 Is this because uClibc convention is to specify this only with
 prototypes which is already being done.
 
 is it possible to rename the conflicting functions in busy box?
 
 This is definitely the wrong solution. If uClibc is clashing with the
 namespace reserved for the application, the symbol name in uClibc
 needs to be fixed not to clash (i.e. appropriately prefixed with
 underscores).

Yes thats better

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

Re: [PATCH] Revert parser_config.[ch]: remove duplicated hidden functions

[Khem Raj]

On May 6, 2013, at 9:10 PM, Vineet Gupta vineet.gup...@synopsys.com wrote:

 This attribute_hidden should not be resurrected.
 
 Is this because uClibc convention is to specify this only with prototypes 
 which is
 already being done.

is it possible to rename the conflicting functions in busy box?
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Bison build failure on uClibc ARM

[Khem Raj]

On Apr 8, 2013, at 12:31 PM, Tux Mason tuxma...@gmail.com wrote:

 Kindly pardon the late reply.
 
 Yes I was using the master branch. I enabled UCLIBC_HAS_ADVANCED_REALTIME
 in the .config.
 Disabling this option enables a successful build of bison but breaks other
 applications like psmisc and sysvinit which rely on posix_memalign.
 


yes, uclibc's spawn.h is not detected right by packages using gnulib
and you end up with these errors. So your options are to feed in the cached
configuration to autconf e.g. 

http://git.openembedded.org/openembedded-core/commit/?id=c5337326005c975425b1eb2b62796e9b33f72ac3

or another option is to go and fix gnulib in the package

something like this

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/coreutilsid=f4bbd20381bd06824f279e19fa0d0db6bae7b53a

 Kind regards,
 Daniel
 
 On Thu, Mar 7, 2013 at 9:13 PM, Bernhard Reutner-Fischer 
 rep.dot@gmail.com wrote:
 
 On 1 March 2013 14:07, Tux Mason tuxma...@gmail.com wrote:
 Hello,
 
 Am building a uClibc toolchain for use on my odroid X2. Bison fails with
 the following error;
 
 arm-zero-linux-uclibcgnueabi-gcc  -std=gnu99  -I.
 -I/home/lfs/tuxdev.git/toolchain-build/bison-2.7/lib  -I../intl
 -I/tools-arm/include  -g -O2 -MT snprintf.o -MD -MP -MF
 .deps/snprintf.Tpo
 -c -o snprintf.o
 /home/lfs/tuxdev.git/toolchain-build/bison-2.7/lib/snprintf.c
 mv -f .deps/snprintf.Tpo .deps/snprintf.Po
 arm-zero-linux-uclibcgnueabi-gcc  -std=gnu99  -I.
 -I/home/lfs/tuxdev.git/toolchain-build/bison-2.7/lib  -I../intl
 -I/tools-arm/include  -g -O2 -MT spawn_faction_addclose.o -MD -MP -MF
 .deps/spawn_faction_addclose.Tpo -c -o spawn_faction_addclose.o
 
 /home/lfs/tuxdev.git/toolchain-build/bison-2.7/lib/spawn_faction_addclose.c
 
 /home/lfs/tuxdev.git/toolchain-build/bison-2.7/lib/spawn_faction_addclose.c:
 In function 'posix_spawn_file_actions_addclose':
 
 /home/lfs/tuxdev.git/toolchain-build/bison-2.7/lib/spawn_faction_addclose.c:50:19:
 error: 'posix_spawn_file_actions_t' has no member named '_used'
 
 Has anyone experienced the above failure? Any pointers will be greatly
 appreciated.
 
 sounds like our partial spawn implementation bites, although there is a
 _used
 member in posix_spawn_file_actions_t on master, AFAICS.
 
 Can you reproduce this on master? If so, i assume you have spawn
 enabled in your .config?
 
 thanks,
 
 ___
 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

[PATCH] i386/sysdep.h: Remove STABS_* macros

[Khem Raj]

uclibc is compiled with elf/dwarf and secondly HAVE_CPP_ASM_DEBUGINFO
is not defined so we generate bogus .stab sections needlessly

Some of post processing tools get confused when they see both
dwarf and stab sections

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 libc/sysdeps/linux/i386/sysdep.h |   27 ---
 1 file changed, 27 deletions(-)

diff --git a/libc/sysdeps/linux/i386/sysdep.h b/libc/sysdeps/linux/i386/sysdep.h
index 983c4f5..7a8d2e2 100644
--- a/libc/sysdeps/linux/i386/sysdep.h
+++ b/libc/sysdeps/linux/i386/sysdep.h
@@ -43,12 +43,9 @@
incomplete stabs information.  Fake some entries here which specify
the current source file.  */
 #defineENTRY(name) 
  \
-  STABS_CURRENT_FILE1()\
-  STABS_CURRENT_FILE(name)   \
   ASM_GLOBAL_DIRECTIVE C_SYMBOL_NAME(name);  \
   ASM_TYPE_DIRECTIVE (C_SYMBOL_NAME(name),@function) \
   .align ALIGNARG(4);\
-  STABS_FUN(name)\
   C_LABEL(name)
  \
   cfi_startproc; \
   CALL_MCOUNT
@@ -57,30 +54,6 @@
 #define END(name)\
   cfi_endproc;   \
   ASM_SIZE_DIRECTIVE(name)   \
-  STABS_FUN_END(name)
-
-#ifdef HAVE_CPP_ASM_DEBUGINFO
-/* Disable that goop, because we just pass -g through to the assembler
-   and it generates proper line number information directly.  */
-# define STABS_CURRENT_FILE1(name)
-# define STABS_CURRENT_FILE(name)
-# define STABS_FUN(name)
-# define STABS_FUN_END(name)
-#else
-/* Remove the following two lines once the gdb bug is fixed.  */
-#define STABS_CURRENT_FILE(name) \
-  STABS_CURRENT_FILE1 (#name)
-#define STABS_CURRENT_FILE1(name)\
-  1: .stabs name,100,0,0,1b;
-/* Emit stabs definition lines.  We use F(0,1) and define t(0,1) as `int',
-   the same way gcc does it.  */
-#define STABS_FUN(name) STABS_FUN2(name, name##:F(0,1))
-#define STABS_FUN2(name, namestr)\
-  .stabs int:t(0,1)=r(0,1);-2147483648;2147483647;,128,0,0,0;
  \
-  .stabs #namestr,36,0,0,name;
-#define STABS_FUN_END(name)  \
-  1: .stabs ,36,0,0,1b-name;
-#endif
 
 /* If compiled for profiling, call `mcount' at the start of each function.  */
 #ifdef PROF
-- 
1.7.9.5

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

Re: segfault of test on buildroot system

[Khem Raj]

On Friday, March 15, 2013, Alexander Varnin fenix...@mail.ru wrote:
 Hello.
 I'm using buildroot based system with ARM samsung processor (s3c2443).
 I've found a case, when i get segfault in my application. Using x86
debian compilers doesn't reproduce error.
 Attaching test program to this letter. There is an exception getting
throw from constructor of child-class (DisplayPassDevice). At that time
parent destructor (~PassageDevice) getting called. When exiting from parent
destructor i got segfault.
 # ./throw
 ~PassageDevice
 Aborted (core dumped)

 One more necessary condition. The bug appears only when i compile my code
with pthread:
 ../minipos-OS-build/host/usr/bin/arm-linux-g++ throw.cpp -o throw
-lpthread

Do you use old abi by any chance?

 When i compile without -lpthread flag, program works OK.
 # ./throw
 ~PassageDevice
 catched

 I don't know what does this problem belongs to, so i write there for
help. Probably you'll just point me, where to report it.
 Software i use is following: gcc 4.5.4, uClibc 0.9.33.2, linux 3.6.


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

Re: [PATCH 6/7] fstat64: Fix Build warnings with common-generic ABI build

[Khem Raj]

 Thanks for review Markos- so what's the list protocol now - I need to resend 
 all
 the patches again or only send the ones which have changed.
 

resend all. If you have published a pull request then just update the pull 
request
tree.

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

Re: Help with Make error on Ubuntu 12 (x64)

[Khem Raj]

On 02/28/2013 10:15 AM, Jeffrey Walton wrote:

Hi All,

Below is from the build process on Ubuntu x86_64:

$ uname -a
Linux ubuntu-12-x64 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19
12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Has anyone encountered similar? Would anyone be able to point out what
I might be missing?

FWIW, I'm trying to build for a desktop so I can get analysis tools on
the library and its test suite.


so I guess you are using native compiler to do that. Wont work
since most probably your system is glibc based and compiler
is also configured for that. You are better of cross compiling
even if its for same architecture. There are bunch of projects
which can generate cross toolchains for uclibc.



Thanks in advance,
Jeff

   ...
   CC libc/inet/ethers.os
In file included from
/usr/src/linux-headers-3.2.0-38/include/linux/if_ether.h:24:0,
  from ./include/netinet/if_ether.h:26,
  from ./include/netinet/ether.h:26,
  from libc/inet/ethers.c:14:
/usr/src/linux-headers-3.2.0-38/include/linux/types.h:13:2: warning:
#warning Attempt to use kernel headers from user space, see
http://kernelnewbies.org/KernelHeaders; [-Wcpp]
In file included from
/usr/src/linux-headers-3.2.0-38/include/linux/posix_types.h:47:0,
  from /usr/src/linux-headers-3.2.0-38/include/linux/types.h:17,
  from
/usr/src/linux-headers-3.2.0-38/include/linux/if_ether.h:24,
  from ./include/netinet/if_ether.h:26,
  from ./include/netinet/ether.h:26,
  from libc/inet/ethers.c:14:
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:52:24:
error: conflicting types for '__kernel_old_uid_t'
./include/bits/kernel_types.h:40:24: note: previous declaration of
'__kernel_old_uid_t' was here
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:53:24:
error: conflicting types for '__kernel_old_gid_t'
./include/bits/kernel_types.h:41:24: note: previous declaration of
'__kernel_old_gid_t' was here
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:57:22:
error: conflicting types for '__kernel_old_dev_t'
./include/bits/kernel_types.h:42:24: note: previous declaration of
'__kernel_old_dev_t' was here
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:66:22:
error: conflicting types for '__kernel_size_t'
./include/bits/kernel_types.h:28:23: note: previous declaration of
'__kernel_size_t' was here
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:67:14:
error: conflicting types for '__kernel_ssize_t'
./include/bits/kernel_types.h:29:15: note: previous declaration of
'__kernel_ssize_t' was here
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:68:14:
error: conflicting types for '__kernel_ptrdiff_t'
./include/bits/kernel_types.h:30:15: note: previous declaration of
'__kernel_ptrdiff_t' was here
/usr/src/linux-headers-3.2.0-38/include/asm/posix_types.h:91:3: error:
conflicting types for '__kernel_fsid_t'
./include/bits/kernel_types.h:51:3: note: previous declaration of
'__kernel_fsid_t' was here
make: *** [libc/inet/ethers.os] Error 1
jeffrey@ubuntu-12-x64:~/uClibc-0.9.33.2$
___
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

Re: [Buildroot] Confused by the fenv implementation, causing gsl build issues

[Khem Raj]

On Thu, Oct 18, 2012 at 12:14 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:

 So I guess we should simply disable the possibility of enabling fenv
 support on those architectures that don't have the necessary code.

you can unset UCLIBC_HAS_FENV in .config for arm and eventually send a
patch either to disable it automatically for arm or have it
implemented.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Improved strlen for ARM, around 29% faster

[Khem Raj]

On Fri, Sep 28, 2012 at 5:48 PM, Gabriel Gonzalez
gabriel.gonzalez.gar...@gmail.com wrote:
 This version for ARM improves performance mainly unrolling the loop for 
 iterations
 and reducing the instructions need to look for the null character.
 A deeper analysis of this can be found at 
 http://www.gabrielgonzalezgarcia.com/2012/10/02/mystrlen-vs-android-bionics-strlen-on-arm-cpu/
 where you can find some data which back up the performance improvement.
 I have only tested it on a little endian CPU so the BIG ENDIAN chunk might 
 need some testing

 Signed-off-by: Gabriel Gonzalez gabriel.gonzalez.gar...@gmail.com
 ---
  libc/string/arm/strlen.S |  123 
 +++---
  1 file changed, 72 insertions(+), 51 deletions(-)

 diff --git a/libc/string/arm/strlen.S b/libc/string/arm/strlen.S
 index 949e918..b87fbb4 100644
 --- a/libc/string/arm/strlen.S
 +++ b/libc/string/arm/strlen.S
 @@ -46,63 +46,84 @@ strlen:
 bx lr
  #else
  strlen:
 -   bic r1, r0, $3  @ addr of word containing first byte
 -   ldr r2, [r1], $4@ get the first word
 -   andsr3, r0, $3  @ how many bytes are duff?
 -   rsb r0, r3, $0  @ get - that number into counter.
 -   beq Laligned@ skip into main check routine if no
 -   @ more
 -#if __BYTE_ORDER == __BIG_ENDIAN
 -   orr r2, r2, $0xff00 @ set this byte to non-zero
 -   subsr3, r3, $1  @ any more to do?
 -   IT(t, gt)
 -   orrgt   r2, r2, $0x00ff @ if so, set this byte
 -   subsr3, r3, $1  @ more?
 -   IT(t, gt)
 -   orrgt   r2, r2, $0xff00 @ then set.
 -#else
 -   orr r2, r2, $0x00ff @ set this byte to non-zero
 -   subsr3, r3, $1  @ any more to do?
 -   IT(t, gt)
 -   orrgt   r2, r2, $0xff00 @ if so, set this byte
 -   subsr3, r3, $1  @ more?
 -   IT(t, gt)
 -   orrgt   r2, r2, $0x00ff @ then set.
 -#endif
 -Laligned:  @ here, we have a word in r2.  Does it
 -   tst r2, $0x00ff @ contain any zeroes?
 -   IT(, ne)
 -   tstne   r2, $0xff00 @
 -   tstne   r2, $0x00ff @
 -   tstne   r2, $0xff00 @
 -   addne   r0, r0, $4  @ if not, the string is 4 bytes longer
 -   IT(t, ne)
 -   ldrne   r2, [r1], $4@ and we continue to the next word
 -   bne Laligned@
 -Llastword: @ drop through to here once we find a
 +   stmfd   sp!, {v1, v2, v3, v4, v5, v6, v7, lr}
 +
 +   mov v7, a1
 +   ldr v6,  =0x80808080
 +
 +   ##
 +   ## un-aligned address till we get aligned
 +   ##
 +1: tst v7, #3
 +   beq 0f
 +   ldrbv1, [v7], #1
 +   tst v1, #0xFF
 +   beq 4f
 +   bal 1b
 +
 +
 +   ## un-rolling strings
 +   ## as few instructions in the loop
 +   ## as possible
 +   ## - Check whether any position equals 0
 +0: ldmfd   v7!, {v1, v2, v3, v4}
 +   sub v5, v1, v6, LSR #7
 +   and v5, v5, v6
 +   bicsv5, v5, v1
 +   bne 1f
 +   sub v5, v2, v6, LSR #7
 +   and v5, v5, v6
 +   bicsv5, v5, v2
 +   bne 2f
 +   sub v5, v3, v6, LSR #7
 +   and v5, v5, v6
 +   bicsv5, v5, v3
 +   bne 3f
 +   sub v5, v4, v6, LSR #7
 +   and v5, v5, v6
 +   bicsv5, v5, v4
 +   bne 4f
 +   beq 0b
 +
 +4: mov v1, v4
 +   bal 0f
 +3: mov v1, v3
 +   sub v7, v7, #4
 +   bal 0f
 +2: mov v1, v2
 +   sub v7, v7, #8
 +   bal 0f
 +1: sub v7, v7, #12
 +   ## After the loop we calculate the diff
 +   ## between the end and the begining of the str
 +   ##
  #if __BYTE_ORDER == __BIG_ENDIAN
 -   tst r2, $0xff00 @ word that has a zero byte in it
 -   IT(, ne)
 -   addne   r0, r0, $1  @
 -   tstne   r2, $0x00ff @ and add up to 3 bytes on to it
 -   addne   r0, r0, $1  @
 -   tstne   r2, $0xff00 @ (if first three all non-zero, 4th
 -   IT(t, ne)
 -   addne   r0, r0, $1  @  must be zero)
 +0: tst v1, #0xFF00
 +   subeq   v7, v7, #1
 +   tst v1, #0x00FF
 +   subeq   v7, v7, #1
 +   tst v1, #0xFF00
 +   subeq   v7, v7, #1
 +   tst v1, #0x00FF
 +4: subeq   v7, v7, #1
  #else
 -   tst r2, $0x00ff @
 -   IT(, ne)
 -   addne   r0, r0, $1  @
 -   tstne   r2, $0xff00 @ and add up to 3 bytes on to it
 -   addne   r0, r0, $1  @
 -   tstne   r2, $0x00ff

Re: uclibc Upgrade question

[Khem Raj]

On Monday, September 24, 2012, Chirag Barot cba...@positronaccess.com
wrote:
 Hi Everybody,

 We are using uclibc libuClibc-0.9.28 with kernel 2.6.16.1 on a board
based on ppc405.
 We want to upgrade to uclibc 0.9.33, I have few couple of basic questions

 1.   Do we need to regenerate the cross compilation tool-chain ?

Yes


 2.   Do we need to upgrade the kernel to latest

2.6.16 might be OK but you are better off using some thing newer with
0.9.33 since that would have had some testing


 The Primary motivation for upgrade is to migrate to NPTL from
Linuxthreads.


OK

 Regards
 Chirag



 ___
 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

Re: [PATCH 9/9] Rules.mak: disable forced unwind on NPTL.

[Khem Raj]

On Fri, Sep 21, 2012 at 8:29 AM, Florian Fainelli flor...@openwrt.org wrote:

 forced unwind for pthread_cancel handling is broken and triggers spurious
 abort() calls from libgcc. Disable it and use the other method instead.

is it broken for all architectures or some ?
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Regression caused by future merge utent.c, wtent.c: move functions from utxent.c

[Khem Raj]

Hi Peter/Bernhard

We have a regression on master which is that systemd does not boot the system 
anymore
whereas it works fine with 0.9.33 branch so I did not bisecting and this boiled 
down
to below commit. If I revert that then everything is working again. Please take 
a look
what could be wrong here. The commit comment The smaller size on utent.os is 
unexpected, could be due to better inlining/not inlining
does not effuse lot of confidence in this patch. I would ask to revert this 
commit if
there is no easy resolution.

commit 84135275cfeebc0b233c1c96eeada4d4178a0b18
Author: Peter S. Mazinger p...@gmx.net
Date:   Tue Mar 15 15:29:14 2011 +0100

utent.c, wtent.c: move functions from utxent.c

before the change (threads enabled)
   textdata bss dec hex filename
   1107   8 4081523 5f3 libc/misc/utmp/utent.os
152   0   0 152  98 libc/misc/utmp/wtent.os
240   0   0 240  f0 libc/misc/utmp/utxent.os
after the change
   textdata bss dec hex filename
   1072   8 4081488 5d0 libc/misc/utmp/utent.os
157   0   0 157  9d libc/misc/utmp/wtent.os
200   0   0 200  c8 libc/misc/utmp/utxent.os

The smaller size on utent.os is unexpected, could be due to better 
inlining/not inlining

Signed-off-by: Peter S. Mazinger p...@gmx.net
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com


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

Re: Race condition on SIGCANCEL signal in POSIX timers

[Khem Raj]

On Tue, Aug 28, 2012 at 12:16 AM, Carmelo AMOROSO
carmelo.amor...@st.com wrote:
 On 28/08/2012 9.07, mail...@gmx.de wrote:
 Hi,


 Hi,

 [Please keep me on CC:, I'm not subscribed]

 I'm working with current uClibc and had problems with POSIX timers.

 I use the timer with SIGEV_THREAD to create one thread each timer event. It
 seems there is a race condition between the thread waiting on SIGCANCEL 
 signal
 (timer_helper_thread in timer_routine.c) and the default signal handler for 
 this
 signal.
 Many timer events will be lost, because they will be dequeued before
 rt_sigtimedwait() could catch it.

 I found a change on creating the helper thread. (Please see:
 http://git.uclibc.org/uClibc/commit/libpthread/nptl/sysdeps/unix/sysv/linux/timer_routines.c?id=162cfaea20d807f0ae329efe39292a9b22593b41)

 After reverting this change, it works for me as expected.
 Could anybody remember, why this change was necessary?

 I think the comment is wrong:
 /*__sigaddset (ss, SIGCANCEL); - already done by sigfillset */

 Currently SIGCANCEL will not be blocked by sigfillset, I had to reenable the
 __sidaddset() comment.

 I already asked Denys Vlasenko via mail, but didn't get an answer so far.

 Because I'm not subscribed to your bugtracker (and not intent to do so), 
 could
 anybody please report a bug against uClibc or did I miss something and this
 change make any sense?


 Thank you in advance,

 Erik


 we have spotted this issue recently as well, indeed the modifications
 you mentioned have introduced a regression.
 I have the fix in the STLinux uClibc repo
 (http://git.stlinux.com/?p=stm/uclibc.git;a=commit;h=1eed623153b5139c8b5dca08030b3a4a1838d4db).

 It's on my list for upstream to uclibc.org as well.


please commit it upstream too.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] buildsys: clean up libubacktrace linker script handling

[Khem Raj]

On Fri, Jun 15, 2012 at 7:37 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 On 15 June 2012 04:54, Kevin Cernekee cerne...@gmail.com wrote:
 On Wed, Jun 13, 2012 at 12:58 AM, Bernhard Reutner-Fischer
 rep.dot@gmail.com wrote:
 On Tue, Jun 12, 2012 at 04:52:21PM +0100, Carmelo AMOROSO wrote:
On 07/06/2012 19.32, Kevin Cernekee wrote:
 Move the AS_NEEDED insertion into libc/Makefile.in, and add a case to
 the HARDWIRED_ABSPATH substitution command so libubacktrace is handled
 the same way as the other libraries listed in the script.

Looks fine to me.


 Applied, thanks!

 Unfortunately it looks like this could cause some problems when
 bootstrapping a new toolchain.  If the libc.so script references
 libubacktrace, but libubacktrace.so.0 is not yet installed anywhere,
 gcc will throw an error during the final link on the other shared
 libraries:

 rm -f lib/libdl.so lib/libdl.so.0 lib/libdl-0.9.32.1.so
 arm-linux-uclibcgnueabi-gcc -Wl,-EL -shared -Wl,--warn-common
 -Wl,--warn-once -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,defs
 -Wl,-fini,dl_cleanup  -Wl,-soname=libdl.so.0 -nostdlib -o
 lib/libdl-0.9.32.1.so  -Wl,--whole-archive ldso/libdl/libdl_so.a
 -Wl,--no-whole-archive ./lib/interp.os -L./lib ./lib/libc.so
 ./lib/ld-uClibc.so.0
 /ssd/test/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.5.3/libgcc.a
 /ssd/test/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.5.3/libgcc_eh.a
 /ssd/test/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.5.3/../../../../arm-linux-uclibcgnueabi/bin/ld:
 cannot find libubacktrace.so.0
 collect2: ld returned 1 exit status
 make[1]: *** [lib/libdl.so] Error 1


 I did not see this earlier because -nostdlib doesn't actually keep gcc
 from passing ld -L arguments pointing into the sysroot directories.
 So it saw my existing libubacktrace.so.0 from the installed sysroot
 and did not complain that libubacktrace.so.0 was missing from the
 uClibc build tree.

 Maybe we will need to revert back to this technique, at least in some form?

 -# Add the AS_NEEDED entry for libubacktrace.so
 -       if [ -f $(top_builddir)lib/libc.so -a -f
 $(PREFIX)$(RUNTIME_PREFIX)$(MULTILIB_DIR)/$(SHARED_LIBNAME) ] ; then \
 -               echo GROUP ( $(UBACKTRACE_ASNEEDED) ) 
 $(PREFIX)$(DEVEL_PREFIX)$(MULTILIB_DIR)/libc.so; \
 -       fi
 -endif

 I would appreciate any feedback/suggestions.

 What a mess. Carmelo, can you suggest a proper fix please (as
 quick-fix i put the static lib into the libc script just to make it
 link).
 TIA,


This quick fix is wrong since now it will try to ask for static
version of libubacktrace when linking shared libs and PIC binaries and
libubacktrace.a is not PIC
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Future branch status

[Khem Raj]

On Friday, June 15, 2012, Bernhard Reutner-Fischer wrote:


 On 27 April 2012 13:38, Bernhard Reutner-Fischer 
 rep.dot@gmail.comjavascript:;
 wrote:
  On 26 April 2012 18:08, Khem Raj raj.k...@gmail.com javascript:;
 wrote:
  On Thu, Apr 26, 2012 at 8:18 AM, Bernhard Reutner-Fischer
  rep.dot@gmail.com javascript:; wrote:

 Hi,

 FYI, I have reinstated ppc boot now (arch independent deadlock) and

thus will push Peter's whole series ASAP.


So you fixed the problems I was seeing ?
Additionally did you boot it on all major arches ?
Using oe I have been booting sato image




 cheers,

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

Re: Incorrect/incomplete eventfd implementation?

[Khem Raj]

On Wed, May 16, 2012 at 11:00 AM, Eugene Rudoy
gene.de...@googlemail.com wrote:

 After taking a look at what glibc does, I would suggest the following (not
 yet tested) fix (s. attached patch)


Looks ok. send with sign-offs and preferably a testcase now that you have one.

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

Re: restoring spec docs

[Khem Raj]

On Thu, May 3, 2012 at 7:02 PM, Mike Frysinger vap...@gentoo.org wrote:
 after moving from svn to git, the docs/ subdir of trunk/ wasn't migrated
 anywhere.  any suggestions on where to restore these ?  i'm not sure we can
 exclude subdirs when using `git archive`, so we can't add them to the main
 repo.  maybe start a new toplevel git repo and add it to uClibc.git as a
 submodule ?

just readd to docs/ subdir as if they were new files. Do we care for history ?


 the files in question are important to us:
 crt.txt
 elf-64-gen.pdf
 elf.pdf
 psABI-arm.pdf
 psABI-i386.pdf
 psABI-ia64.pdf
 psABI-m8-16.pdf
 psABI-mips.pdf
 psABI-parisc.pdf
 psABI-ppc64.pdf
 psABI-ppc.pdf
 psABI-s390.pdf
 psABI-s390x.pdf
 psABI-sh.txt
 psABI-sparc.pdf
 psABI-x86_64.pdf
 SysV-ABI.pdf
 SysV-Interface-vol1a.pdf
 SysV-Interface-vol1b.pdf
 SysV-Interface-vol2.pdf
 tls.pdf
 tls-ppc64.txt
 tls-ppc.txt
 -mike

 ___
 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

Re: restoring spec docs

[Khem Raj]

On Thu, May 3, 2012 at 10:12 PM, Mike Frysinger vap...@gentoo.org wrote:

 my concern isn't history, it's the 11MB footprint (7.5 when compressed in a
 tarball) mostly due to the pdfs.  we don't want to include that in the release
 tarball when that's only 2.7MB right now.

yes it occured to me later. I think having a separate docs repo makes sense then
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Future branch status

[Khem Raj]

On Thu, Apr 26, 2012 at 8:18 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 Another thing: with LD_SO_CACHE=y O_CLOEXEC is not defined (you removed all 
 the
 _GNU_SOURCE and we did not yet adjust it for susv4) so ldso fails to build 
 with:
  CC ldso/ldso/ldso.oS
 In file included from ldso/ldso/ldso.c:1432:0:
 ldso/ldso/dl-elf.c: In function '_dl_map_cache':
 ldso/ldso/dl-elf.c:54:45: error: 'O_CLOEXEC' undeclared (first use in
 this function)

 Disregard this, i had to fix your OABI vs EABI check since otherwise
 pregen headers
 barfed (since the did not include the config). Fixed now by including
 uClibc_config.h in the
 arm arch_features before the abi check.

I have some patches on top too which are not on the branch I posted
this was one of them

From 7ff5e8b59f629bc83f4dbaf7d76dbecccf50b122 Mon Sep 17 00:00:00 2001
From: Khem Raj raj.k...@gmail.com
Date: Tue, 7 Feb 2012 19:54:17 -0800
Subject: [PATCH] includes: uClibc_arch_features.h now depends on
 uClibc_config.h

Adjust for the dependency so include features.h from
libc-symbols.h which is included on compiler cmdline
which otherwise misses the symbols from uClibc_config.h
since it only included bits/uClibc_arch_features.h

So we include both bits/uClbc_configs.h and bits/uClibc_arch_features.h
in features.h and include features.h in libc-symbols.h
which then takes care of dependencies

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 include/features.h |1 +
 include/libc-symbols.h |2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

Index: git/include/libc-symbols.h
===
--- git.orig/include/libc-symbols.h 2012-02-07 21:09:02.885347078 -0800
+++ git/include/libc-symbols.h  2012-02-07 21:11:56.097355232 -0800
@@ -48,6 +48,9 @@

*/

+#define __need_uClibc_config_h
+# include bits/uClibc_config.h
+#undef __need_uClibc_config_h
 #include bits/uClibc_arch_features.h

 /* Enable declarations of GNU extensions, since we are compiling them.  */
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Future branch status

[Khem Raj]

On Wed, Apr 25, 2012 at 4:53 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 On 24 April 2012 23:54, Peter Mazinger p...@gmx.net wrote:
 Peter,


 I get alot of errors when compiling for x86_64 (i.e. 64bit), e.g.:

 libc/misc/dirent/versionsort.c:16:1: warning: return type defaults to
 'int' [enabled by default]
 libc/misc/dirent/versionsort.c:16:1: warning: function declaration
 isn't a prototype [-Wstrict-prototypes]

 means, your headers do not provide a prototype for versionsort()

 No, it was a typo in the macro name (see surplus 's' in other mail in
 this thread).
 fixed.

 fcntl is a special case, not comparable with the other X64() functions (at 
 least in uClibc), this case can be discussed on ml if you want to.

 Yes, i know. I think the correct guard is
 #if defined __UCLIBC_HAS_LFS__  __WORDSIZE == 32  !defined __NR_fcntl64
 fixed.

 missing comma for ppc32 in posix_fadvise.c -- fixed.

 Another question, on powerpc, i see:

 Makefile.in:139: warning: overriding commands for target
 `include/bits/local_lim.h'
 libpthread/nptl/sysdeps/unix/sysv/linux/Makefile.commonarch:202:
 warning: ignoring old commands for target `include/bits/local_lim.h'

 Can you advise on this on, please?

Bernhard

Be aware that the patches that are eliminated only make it work
on x86 other architectures are still regressing so do first find
the offending patches that cause this.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Future branch status

[Khem Raj]

On Wed, Apr 25, 2012 at 8:21 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 I am of course aware of this, yes. See
 uClibc.org/~aldot/uClibc/psm-future.tar.gz

I saw that and I wanted to reiterate since they are exact list of
patches I have filtered
on https://github.com/kraj/uClibc/tree/future-merge and those don't work.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Future branch status

[Khem Raj]

On Sat, Apr 21, 2012 at 1:37 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:

 Let's leave this out for the merge and look at it after the merge
 (unless you can fix it for the failing arches), ok?

 I'm going through the other commits during the weekend (I have a few
 remarks).


Yes thats a good plan I think. However there are some cleanup fixes that
are sort of obvious and some bug fixes that we can safely take after testing


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

Re: Future branch status

[Khem Raj]

On Thu, Apr 19, 2012 at 3:28 AM, Peter Mazinger p...@gmx.net wrote:
 Hi,

 which 3 patches produce the regressions?

The real problem is in first one other two are just dependent on it.
so they are removed but first one shows up the real problem.

http://uclibc.org/~kraj/future-rebase/0368-hide-locking-related-pthread-functions-in-libc.so.patch

http://uclibc.org/~kraj/future-rebase/0387-linuxthreads.old-hide-a-bunch-of-functions.patch

http://uclibc.org/~kraj/future-rebase/0393-fix-the-different-views-of-the-cleanup-functions.patch


 Is the arm/mips/ppc problem an endianness only problem (does it work on LE 
 but not on BE)?

arm is LE other two are BE


 Thanks, Peter
  Original-Nachricht 
 Datum: Wed, 18 Apr 2012 23:45:22 -0700
 Von: Khem Raj raj.k...@gmail.com
 An: uClibc list uclibc@uclibc.org
 CC: Peter Mazinger p...@gmx.net
 Betreff: Future branch status

 Hi

 I have been trying to sanitize future branch and keep it rebased on
 top of master
 however the branch does introduce regressions. I have identified 3 patches
 which
 lets me boot x11 image on x86 and x86_64 but arm, mips and ppc are still a
 no go
 it boots into console fine but not the x11 image which otherwise boots
 fine on top
 of current master so I consider this as a regression.

 The branch however does have some interesting fixes. So I am going to
 merge the
 bug fixes and trivial fixes first and primarily which dont regress.

 My tree is here

 https://github.com/kraj/uClibc

 which is future branch rebased on top of master.

 Thanks

 -Khem

 --
 NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
 Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
 ___
 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

Re: [PATCH,CFT] libc: add posix_fallocate()

[Khem Raj]

On Tue, Apr 17, 2012 at 12:30 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
 ---
  include/fcntl.h                                  |    4 +-
  libc/sysdeps/linux/common/Makefile.in            |    3 +-
  libc/sysdeps/linux/common/bits/kernel-features.h |    8 ++
  libc/sysdeps/linux/common/posix_fallocate.c      |   43 
  libc/sysdeps/linux/common/posix_fallocate64.c    |   39 +++
  libc/sysdeps/linux/common/stubs.c                |    4 +
  test/.gitignore                                  |    1 +
  test/unistd/Makefile.in                          |    3 +
  test/unistd/tst-posix_fallocate.c                |  121 
 ++
  9 files changed, 222 insertions(+), 4 deletions(-)
  create mode 100644 libc/sysdeps/linux/common/posix_fallocate.c
  create mode 100644 libc/sysdeps/linux/common/posix_fallocate64.c
  create mode 100644 test/unistd/tst-posix_fallocate.c


Looks ok to me. Did you test it on a 32bit and a 64 bit arch ?
mips would be interesting.

 diff --git a/include/fcntl.h b/include/fcntl.h
 index 26ad1fe..c4a47af 100644
 --- a/include/fcntl.h
 +++ b/include/fcntl.h
 @@ -210,9 +210,7 @@ extern int posix_fadvise64 (int __fd, __off64_t __offset, 
 __off64_t __len,

  #endif

 -#if 0 /*  defined __UCLIBC_HAS_ADVANCED_REALTIME__ */
 -
 -/* FIXME -- uClibc should probably implement these... */
 +#if defined __UCLIBC_HAS_ADVANCED_REALTIME__

  /* Reserve storage for the data of the file associated with FD.

 diff --git a/libc/sysdeps/linux/common/Makefile.in 
 b/libc/sysdeps/linux/common/Makefile.in
 index 3b5763c..cddcd74 100644
 --- a/libc/sysdeps/linux/common/Makefile.in
 +++ b/libc/sysdeps/linux/common/Makefile.in
 @@ -81,7 +81,8 @@ CSRC-$(UCLIBC_HAS_REALTIME) += clock_getres.c 
 clock_gettime.c clock_settime.c \
        sched_get_priority_max.c sched_get_priority_min.c sched_getscheduler.c 
 \
        sched_rr_get_interval.c sched_setparam.c sched_setscheduler.c 
 sigqueue.c
  # 
 clock_getcpuclockid|clock_nanosleep|mq_timedreceive|mq_timedsend|posix_fadvise|posix_fallocate|posix_madvise|posix_memalign|posix_mem_offset|posix_spawnattr_destroy|posix_spawnattr_init|posix_spawnattr_getflags|posix_spawnattr_setflags|posix_spawnattr_getpgroup|posix_spawnattr_setpgroup|posix_spawnattr_getschedparam|posix_spawnattr_setschedparam|posix_spawnattr_getschedpolicy|posix_spawnattr_setschedpolicy|posix_spawnattr_getsigdefault|posix_spawnattr_setsigdefault|posix_spawnattr_getsigmask|posix_spawnattr_setsigmask|posix_spawnattr_init|posix_spawnattr_setflags|posix_spawnattr_setpgroup|posix_spawnattr_setschedparam|posix_spawnattr_setschedpolicy|posix_spawnattr_setsigdefault|posix_spawnattr_setsigmask|posix_spawn_file_actions_addclose|posix_spawn_file_actions_addopen|posix_spawn_file_actions_adddup2|posix_spawn_file_actions_addopen|posix_spawn_file_actions_destroy|posix_spawn_file_actions_init|posix_spawn_file_actions_init|posix_spawn|posix_spawnp|posix_spawnp|posix_typ
  ed_mem_get_info|pthread_mutex_timedlock|sem_timedwait
 -CSRC-$(UCLIBC_HAS_ADVANCED_REALTIME) += posix_fadvise64.c posix_fadvise.c
 +CSRC-$(UCLIBC_HAS_ADVANCED_REALTIME) += posix_fadvise64.c posix_fadvise.c \
 +       posix_fallocate.c posix_fallocate64.c
  CSRC-$(UCLIBC_SUSV4_LEGACY) += utime.c
  CSRC-$(UCLIBC_HAS_EPOLL) += epoll.c
  CSRC-$(UCLIBC_HAS_XATTR) += xattr.c
 diff --git a/libc/sysdeps/linux/common/bits/kernel-features.h 
 b/libc/sysdeps/linux/common/bits/kernel-features.h
 index 5ea85d2..be00dda 100644
 --- a/libc/sysdeps/linux/common/bits/kernel-features.h
 +++ b/libc/sysdeps/linux/common/bits/kernel-features.h
 @@ -494,6 +494,14 @@
  # define __ASSUME_PRIVATE_FUTEX        1
  #endif

 +/* Support for fallocate was added in 2.6.23,
 +   on s390 only after 2.6.23-rc1, on alpha only after 2.6.33-rc1.  */
 +#if __LINUX_KERNEL_VERSION = 0x020617 \
 +     (!defined __s390__ || __LINUX_KERNEL_VERSION = 0x020618) \
 +     (!defined __alpha__ || __LINUX_KERNEL_VERSION = 0x020621)
 +# define __ASSUME_FALLOCATE 1
 +#endif
 +
  /* getcpu is a syscall for x86-64 since 3.1.  */
  #if defined __x86_64__  __LINUX_KERNEL_VERSION = 0x030100
  # define __ASSUME_GETCPU_SYSCALL        1
 diff --git a/libc/sysdeps/linux/common/posix_fallocate.c 
 b/libc/sysdeps/linux/common/posix_fallocate.c
 new file mode 100644
 index 000..9aaa6ce
 --- /dev/null
 +++ b/libc/sysdeps/linux/common/posix_fallocate.c
 @@ -0,0 +1,43 @@
 +/* vi: set sw=4 ts=4: */
 +/*
 + * posix_fallocate() for uClibc
 + * 
 http://www.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
 + *
 + * Copyright (C) 2000-2006 Erik Andersen ander...@uclibc.org
 + *
 + * Licensed under the LGPL v2.1 or later, see the file COPYING.LIB in this 
 tarball.
 + */
 +
 +#include sys/syscall.h
 +#include fcntl.h
 +#include bits/kernel-features.h
 +#include stdint.h
 +
 +#if defined __NR_fallocate
 +int posix_fallocate(int fd, __off_t offset, __off_t len)
 +{
 +       int ret;
 +
 +# if 

Re: getaddrinfo performance problems

[Khem Raj]

On Mon, Apr 16, 2012 at 3:02 PM, Ed W li...@wildgooses.com wrote:
 OK, please see attached version 2 of my patch which I believe implements
 this satisfactorarily

 As before the motivation is to avoid making DNS queries when calling
 getaddrinfo with a numerical IP address.  Performance improves dramatically
 in such situations

Does this solve your original problem ?
is there some testcase to go along with this for performance ?


 Grateful if others with more experience will verify and commit

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

Re: [PATCH] spawn: Expose posix_spwanattr_* functions

[Khem Raj]

On Fri, Apr 13, 2012 at 5:03 PM, Mike Frysinger vap...@gentoo.org wrote:

 let's fix gnulib then.  this seems like it'll add code bloat overall -- a
 single memory store vs a full func call.

yeah I think all I needed by to provide librt for configure checks
since it assumes that these functions
can only exist in libc. Once I did that then it started to behave.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] spawn: Expose posix_spwanattr_* functions

[Khem Raj]

Static inline wont work on packages like gnulib
where it will generate its own spawn.h

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 include/spawn.h |  155 
 librt/spawn.c   |  162 +++
 2 files changed, 195 insertions(+), 122 deletions(-)

diff --git a/include/spawn.h b/include/spawn.h
index 95fff35..1d96467 100644
--- a/include/spawn.h
+++ b/include/spawn.h
@@ -64,6 +64,8 @@ typedef struct
 #define POSIX_SPAWN_SETSCHEDULER   0x20
 #ifdef __USE_GNU
 # define POSIX_SPAWN_USEVFORK  0x40
+#else
+# define POSIX_SPAWN_USEVFORK  0x00
 #endif
 
 
@@ -73,7 +75,8 @@ typedef struct
| POSIX_SPAWN_SETSIGMASK\
| POSIX_SPAWN_SETSCHEDPARAM \
| POSIX_SPAWN_SETSCHEDULER  \
-   | POSIX_SPAWN_USEVFORK)
+   | POSIX_SPAWN_USEVFORK  \
+   )
 
 __BEGIN_DECLS
 
@@ -101,167 +104,75 @@ extern int posix_spawnp (pid_t *__pid, const char 
*__file,
 
 
 /* Initialize data structure with attributes for `spawn' to default values.  */
-static inline
-int posix_spawnattr_init (posix_spawnattr_t *__attr)
-{
-  memset (__attr, 0, sizeof (*__attr));
-  return 0;
-}
+extern int posix_spawnattr_init (posix_spawnattr_t *__attr);
 
 /* Free resources associated with ATTR.  */
-static inline
-int posix_spawnattr_destroy (posix_spawnattr_t *__attr)
-{
-  return 0;
-}
+extern int posix_spawnattr_destroy (posix_spawnattr_t *__attr);
 
 /* Store signal mask for signals with default handling from ATTR in
SIGDEFAULT.  */
-static inline
-int posix_spawnattr_getsigdefault (const posix_spawnattr_t *
+extern int posix_spawnattr_getsigdefault (const posix_spawnattr_t *
  __restrict __attr,
- sigset_t *__restrict __sigdefault)
-{
-  memcpy (__sigdefault, __attr-__sd, sizeof (sigset_t));
-  return 0;
-}
+ sigset_t *__restrict __sigdefault);
 
 /* Set signal mask for signals with default handling in ATTR to SIGDEFAULT.  */
-static inline
-int posix_spawnattr_setsigdefault (posix_spawnattr_t *__restrict __attr,
+extern int posix_spawnattr_setsigdefault (posix_spawnattr_t *__restrict __attr,
  const sigset_t *__restrict
- __sigdefault)
-{
-  memcpy (__attr-__sd, __sigdefault, sizeof (sigset_t));
-  return 0;
-}
+ __sigdefault);
 
 /* Store signal mask for the new process from ATTR in SIGMASK.  */
-static inline
-int posix_spawnattr_getsigmask (const posix_spawnattr_t *__restrict
+extern int posix_spawnattr_getsigmask (const posix_spawnattr_t *__restrict
   __attr,
-  sigset_t *__restrict __sigmask)
-{
-  memcpy (__sigmask, __attr-__ss, sizeof (sigset_t));
-  return 0;
-}
+  sigset_t *__restrict __sigmask);
 
 /* Set signal mask for the new process in ATTR to SIGMASK.  */
-static inline
-int posix_spawnattr_setsigmask (posix_spawnattr_t *__restrict __attr,
-  const sigset_t *__restrict __sigmask)
-{
-  memcpy (__attr-__ss, __sigmask, sizeof (sigset_t));
-  return 0;
-}
+extern int posix_spawnattr_setsigmask (posix_spawnattr_t *__restrict __attr,
+  const sigset_t *__restrict __sigmask);
 
 /* Get flag word from the attribute structure.  */
-static inline
-int posix_spawnattr_getflags (const posix_spawnattr_t *__restrict
+extern int posix_spawnattr_getflags (const posix_spawnattr_t *__restrict
 __attr,
-short int *__restrict __flags)
-{
-  *__flags = __attr-__flags;
-  return 0;
-}
+short int *__restrict __flags);
 
 /* Store flags in the attribute structure.  */
-static inline
-int posix_spawnattr_setflags (posix_spawnattr_t *_attr,
-short int __flags)
-{
-  /* Check no invalid bits are set.  */
-  if (__flags  ~__POSIX_SPAWN_MASK)
-return EINVAL;
-
-  _attr-__flags = __flags;
-  return 0;
-}
+extern int posix_spawnattr_setflags (posix_spawnattr_t *_attr,
+short int __flags);
 
 /* Get process group ID from the attribute structure.  */
-static inline
-int posix_spawnattr_getpgroup (const posix_spawnattr_t *__restrict
- __attr, pid_t *__restrict __pgroup)
-{
-  *__pgroup = __attr-__pgrp;
-  return 0;
-}
+extern int posix_spawnattr_getpgroup (const posix_spawnattr_t *__restrict
+ __attr, pid_t *__restrict __pgroup);
 
 /* Store process group ID in the attribute structure

mmap64: use INLINE_SYSCALL() helper fails for ppc

[Khem Raj]

I am seeing build failure on ppc


| libc/libc_so.a(mmap64.os): In function `mmap64':
| 
/home/kraj/work/openembedded-core/build/tmp-uclibc/work/ppc603e-oe-linux-uclibc/uclibc-0.9.33+gitra7c4e889e9c36fc19198654ada229aaa11955ee6-r6.0/git/libc/sysdeps/linux/common/mmap64.c:60:
undefined reference to `__illegally_sized_syscall_arg6'
| collect2: error: ld returned 1 exit status


It could be related to

Author: Mike Frysinger vap...@gentoo.org
Date:   Wed Apr 11 16:05:08 2012 -0400

mmap64: use INLINE_SYSCALL() helper

Signed-off-by: Mike Frysinger vap...@gentoo.org


anybody else seeing it on master ?

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

Re: gcc + uclibc

[Khem Raj]

On Tue, Apr 10, 2012 at 11:43 AM, Mike Frysinger vap...@gentoo.org wrote:
 On Tuesday 10 April 2012 13:06:44 Alberich de megres wrote:
 After some testings, and check your script and link (thanks for both),
 i'm having a different problem:

 while building gcc step 2, and libgcc:
 libgcc/../gcc/libgcc2.c:29:
 /opt/x/usr/include/pthread.h:25:19: fatal error: sched.h: No such file
 or directory

 In pthread.h I can see the include line is this one:
 #include sched.h

 while headers are located at include/linux/sched.h

 shouldn't it be:
 #include linux/sched.h

 no.  uClibc provides sched.h.  you should see why it wasn't installed in the
 uClibc headers stage.

probably you dont have
UCLIBC_HAS_REALTIME=y in .config

 -mike

 ___
 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

Re: [PATCH V2 8/8] MIPS: Fix more *_NONBLOCK definitions

[Khem Raj]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/2012 01:31 PM, Kevin Cernekee wrote:
 MIPS defines O_NONBLOCK differently from most other architectures.
 The common definitions use 04000 / 0x800, but MIPS uses 0200 / 0x80
 instead.
 
 After seeing a problem report involving one of the O_NONBLOCK 
 derivatives, I looked through the tree to see what else might be 
 affected.  Here is what I found:

We already have this kind of patch in future branch IIRC

 
 O_NONBLOCK: correct SOCK_NONBLOCK: correct (tst-sock-nonblock
 passes) EPOLL_NONBLOCK: correct SFD_NONBLOCK: correct (fixed in
 commit f87898ca; tst-signalfd passes) TFD_NONBLOCK: incorrect
 (tst-timerfd fails) IN_NONBLOCK: incorrect (tst-inotify fails)
 
 The proposed change is to add #ifdef clauses for __mips__, similar
 to what was done for SFD_NONBLOCK in include/sys/signalfd.h .  This
 fixes the two failing test cases.
 
 Signed-off-by: Kevin Cernekee cerne...@gmail.com --- 
 libc/sysdeps/linux/common/sys/inotify.h |   11 +++ 
 libc/sysdeps/linux/common/sys/timerfd.h |   11 +++ 2 files
 changed, 22 insertions(+), 0 deletions(-)
 
 diff --git a/libc/sysdeps/linux/common/sys/inotify.h
 b/libc/sysdeps/linux/common/sys/inotify.h index dc4e19d..4a10d6b
 100644 --- a/libc/sysdeps/linux/common/sys/inotify.h +++
 b/libc/sysdeps/linux/common/sys/inotify.h @@ -23,6 +23,16 @@
 
 
 /* Flags for the parameter of inotify_init1.  */ +#if defined
 __mips__ +enum +  { +IN_CLOEXEC = 0200, +#define IN_CLOEXEC
 IN_CLOEXEC +IN_NONBLOCK = 0200 +#define IN_NONBLOCK
 IN_NONBLOCK +  }; + +#else enum { IN_CLOEXEC = 0200, @@ -30,6
 +40,7 @@ enum IN_NONBLOCK = 04000 #define IN_NONBLOCK IN_NONBLOCK 
 }; +#endif
 
 
 /* Structure describing an inotify event.  */ diff --git
 a/libc/sysdeps/linux/common/sys/timerfd.h
 b/libc/sysdeps/linux/common/sys/timerfd.h index c1bb06f..141338e
 100644 --- a/libc/sysdeps/linux/common/sys/timerfd.h +++
 b/libc/sysdeps/linux/common/sys/timerfd.h @@ -23,6 +23,16 @@
 
 
 /* Bits to be set in the FLAGS parameter of `timerfd_create'.  */ 
 +#if defined __mips__ +enum +  { +TFD_CLOEXEC = 0200, 
 +#define TFD_CLOEXEC TFD_CLOEXEC +TFD_NONBLOCK = 0200 +#define
 TFD_NONBLOCK TFD_NONBLOCK +  }; + +#else enum { TFD_CLOEXEC =
 0200, @@ -30,6 +40,7 @@ enum TFD_NONBLOCK = 04000 #define
 TFD_NONBLOCK TFD_NONBLOCK }; +#endif
 
 
 /* Bits to be set in the FLAGS parameter of `timerfd_settime'.  */

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ArSAACgkQuwUzVZGdMxQe4QCfayl21bSKN+i/tmV215Y9sBNU
iGwAn3Jst/+F2YEiowvsgPU9lq/ushGY
=9yaC
-END PGP SIGNATURE-
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH V2 8/8] MIPS: Fix more *_NONBLOCK definitions

[Khem Raj]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/07/2012 02:22 PM, Kevin Cernekee wrote:
 On Sat, Apr 7, 2012 at 2:09 PM, Khem Raj raj.k...@gmail.com
 wrote:
 After seeing a problem report involving one of the O_NONBLOCK 
 derivatives, I looked through the tree to see what else might
 be affected.  Here is what I found:
 
 We already have this kind of patch in future branch IIRC
 
 I think TFD_NONBLOCK and IN_NONBLOCK are still missing on both
 master and future?


that could be I dont have handy access to check ATM
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+AvbcACgkQuwUzVZGdMxRXGACff0wMt7Udo27dWLi/UKbz2VGV
BvcAn107xVSeC1lTHRJfkGbjPdwZnjVk
=MLeR
-END PGP SIGNATURE-
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: gcc + uclibc

[Khem Raj]

On Mon, Apr 2, 2012 at 1:13 AM, Alberich de megres
alberich...@gmail.com wrote:
 Hello!

 I'm trying to understand the toolchain creation, by building one. I
 want to learn how they work.
 I'm building one for arm, with:
 - binutils 2.22
 - kernel 3.1.8 headers
 - gcc 4.6.2


I have some rudimentary scripts for building them here
https://github.com/kraj/ct-scripts

reading through them should help


 When compiling gcc final stage I got the following error:


 /home/abm/kr/xenv-0.3.01/work/rpi/build/gcc-4.6.2/./gcc/xgcc
 -B/home/abm/kr/xenv-0.3.01/work/rpi/build/gcc-4.6.2/./gcc/
 -B/opt/xenv/x-tools/arm-none-eabi/bin/
 -B/opt/xenv/x-tools/arm-none-eabi/lib/ -isystem
 /opt/xenv/x-tools/arm-none-eabi/include -isystem
 /opt/xenv/x-tools/arm-none-eabi/sys-include    -g -O2 -O2  -g -O2
 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
 -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
 -Wold-style-definition  -isystem ./include  -fno-inline
 -Wno-missing-prototypes -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
 -fno-stack-protector   -I. -I. -I../.././gcc
 -I/home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc
 -I/home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc/.
 -I/home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc/../gcc
 -I/home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc/../include
 -DHAVE_CC_TLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep
 -DL_muldi3 -c 
 /home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc/../gcc/libgcc2.c
 \
 In file included from
 /home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc/../gcc/libgcc2.c:29:0:
 /home/abm/kr/xenv-0.3.01/work/rpi/src/gcc-4.6.2/libgcc/../gcc/tsystem.h:87:19:
 fatal error: stdio.h: No such file or directory
 compilation terminated.
 make[2]: *** [_muldi3.o] Error 1
 make[2]: Leaving directory
 `/home/abm/kr/xenv-0.3.01/work/rpi/build/gcc-4.6.2/arm-none-eabi/libgcc'
 make[1]: *** [all-target-libgcc] Error 2
 make[1]: Leaving directory `/home/abm/kr/xenv-0.3.01/work/rpi/build/gcc-4.6.2'
 make: *** [all] Error 2


 But stdio.h is there in the sysroot directory:
 find . | grep stdio
 ./usr/arm-linux-uclibc/usr/include/bits/uClibc_stdio.h
 ./usr/arm-linux-uclibc/usr/include/bits/stdio.h
 ./usr/arm-linux-uclibc/usr/include/stdio.h

 Thanks!!
 Alberich


 -

 Some varieables:
 XSYSROOT=/opt/x/
 XPREFIX=/opt/x/x-tools
 export TARGET=arm-unknown-linux-gnu
 ENDIAN=little
 export ARCH=arm
 export CROSS_COMPILE=${TARGET}-

 -

 The config lines I'm using are:

 binutils
 gcc step 1
  ${XECURSRC}/configure --prefix=${XPREFIX} --target=${TARGET}  \
   --without-headers --disable-threads --with-newlib \
   --disable-shared  --disable-libssp \
   --disable-libgomp --disable-libmudflap --disable-libquadmath \
   --enable-languages=c
  make all-gcc all-target-libgcc
 make install-gcc install-target-libgcc

 uclibc
  make allnoconfig ARCH=$ARCH CROSS=$CROSS_COMPILE PREFIX=$XSYSROOT
  echo 
  s/^[# ]*\\(TARGET_[a-zA-Z0-9_\\-]*\\).*/# \1 is not set/g
  s/^[# ]*\(TARGET_${ARCH}\).*/\1=y/g
  s/^[# ]*TARGET_ARCH[ =].*/TARGET_ARCH=\${ARCH}\/g
  s/^[# ]*TARGET_SUBARCH[= ].*/TARGET_SUBARCH=\\/g
  s@^KERNEL_HEADERS=.*@KERNEL_HEADERS=\${XSYSROOT}/usr/include\@g
  s/^[# ]*ARCH_BIG_ENDIAN=.*/ARCH_LITTLE_ENDIAN=y\nARCH_WANTS_LITTLE_ENDIAN=y/g
  s/^[# 
 ]*ARCH_LITTLE_ENDIAN=.*/ARCH_LITTLE_ENDIAN=y\nARCH_WANTS_LITTLE_ENDIAN=y/g
  s/^[# ]*\\(ARCH_WANTS_BIG_ENDIAN\\)=.*/# \1 is not set/g
  s/^[# ]*HAS_NO_THREADS.*/# HAS_NO_THREADS is not set/g
  s/^[# ]*UCLIBC_HAS_THREADS.*/UCLIBC_HAS_THREADS=y/g
  /^[# ]*UCLIBC_HAS_THREADS.*/i\UCLIBC_HAS_THREADS_NATIVE=y
  /^[# ]*UCLIBC_HAS_THREADS.*/a\UCLIBC_HAS_TLS=y\n#
 PTHREADS_DEBUG_SUPPORT is not set
   .tmp.xenv_sed_file
  sed -f .tmp.xenv_sed_file   .config  .xenv_config
  cp .xenv_config .config
  make ARCH=$ARCH CROSS=$CROSS_COMPILE PREFIX=$XSYSROOT
 install_headers install_startfiles
  make CROSS=$CROSS_COMPILE PREFIX=$XSYSROOT install

 gcc_final
  ${XECURSRC}/configure --prefix=${XPREFIX} --target=${TARGET}
 --with-sysroot=${XSYSROOT} \
  --disable-libssp --disable-libgomp \
  --disable-libmudflap --disable-libquadmath \
  --enable-languages=c,c++ \
  --disable-nls --disable-multilib

 make
 make install
 ___
 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

Re: incorrect print -1 using %hhd

[Khem Raj]

Signed ness of char is arch dependent eg ppc defaults to signed but arm
doesn't so demanding a given signedness ain't that bad
 On Mar 28, 2012 12:52 AM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:

 On 28 March 2012 08:38, Andrew Rybchenko andrew.rybche...@oktetlabs.ru
 wrote:
  On 03/28/2012 02:36 AM, Michael Deutschmann wrote:
 
  On Tue, 27 Mar 2012, Mike Frysinger wrote:
 
  On Tuesday 27 March 2012 10:28:29 Andrew Rybchenko wrote:
 
  Is it known issue that uClibc 0.9.32 incorrectly prints -1 using
  %hhd (and %hhi) specifier? The following program:
 
  please file a bug
 
  No need, this is bug #1783.
 
  It was closed as fixed-in-the-next-release when I reported it against
  0.9.31, but somehow the fix hasn't percolated into any release version
 of
  uClibc yet.
 
  The fix is really simple.  Just change the cast from (char) to
 (signed
  char) in libc/stdio/_load_inttype.c .  The bug was introduced not by
 any
  change in the sourcecode itself, but because the Makefiles started
  specifying -funsigned-char everywhere.

 And that's exactly why using -funsigned-char is a really bad idea.
 ___
 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

Re: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option

[Khem Raj]

On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger vap...@gentoo.org wrote:
 The _start symbol is the default entry point for ELFs, so there should be
 no need to manually specify this.  The background motivation is that this
 causes issues for ports that have a symbol prefix (like Blackfin) and so
 they don't have a _start symbol -- it's named __start.

on MIPS its also __start unlike others where it is _start
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option

[Khem Raj]

On Sun, Mar 25, 2012 at 12:58 AM, Mike Frysinger vap...@gentoo.org wrote:
 On Sunday 25 March 2012 03:23:38 Khem Raj wrote:
 On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger vap...@gentoo.org wrote:
  The _start symbol is the default entry point for ELFs, so there should be
  no need to manually specify this.  The background motivation is that this
  causes issues for ports that have a symbol prefix (like Blackfin) and so
  they don't have a _start symbol -- it's named __start.

 on MIPS its also __start unlike others where it is _start

 ok, i'll ponder exposing __USER_LABEL_PREFIX__ to the build system somehow
 then so it automatically selects the right _start

if binutils/ld is configured for right emulation (which it should be)
that should take care of it automatically
though so your patch is ok.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option

[Khem Raj]

On Sun, Mar 25, 2012 at 12:42 PM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:


 Khem Raj raj.k...@gmail.com wrote on 2012/03/25 20:23:04:

 From: Khem Raj raj.k...@gmail.com
 To: Joakim Tjernlund joakim.tjernl...@transmode.se
 Cc: uclibc@uclibc.org, uclibc-boun...@uclibc.org, Mike Frysinger 
 vap...@gentoo.org
 Date: 2012/03/25 20:23
 Subject: Re: [RFC/PATCH] ldso: drop -Wl,-e,_start linking option

 On Sun, Mar 25, 2012 at 10:30 AM, Joakim Tjernlund
 joakim.tjernl...@transmode.se wrote:
 
  On Sun, Mar 25, 2012 at 12:58 AM, Mike Frysinger vap...@gentoo.org 
  wrote:
   On Sunday 25 March 2012 03:23:38 Khem Raj wrote:
   On Sat, Mar 24, 2012 at 11:58 PM, Mike Frysinger vap...@gentoo.org 
   wrote:
The _start symbol is the default entry point for ELFs, so there 
should be
no need to manually specify this.  The background motivation is that 
this
causes issues for ports that have a symbol prefix (like Blackfin) 
and so
they don't have a _start symbol -- it's named __start.
  
   on MIPS its also __start unlike others where it is _start
  
   ok, i'll ponder exposing __USER_LABEL_PREFIX__ to the build system 
   somehow
   then so it automatically selects the right _start
 
  if binutils/ld is configured for right emulation (which it should be)
  that should take care of it automatically
  though so your patch is ok.
 
  I think the problem is that ldso.c expects start to be named _start so
  you can't just rename it __start.
  You could define _start = __start in arch code that need it though.
 

 isnt it arch specific function in ldso/arch/dl-startup.h ?

 It is in ldso/ldso/ldso.c last I checked.


right thats the consumer of the definition so I think adding alias for __start
in the definition will fix this problem.

  Jocke

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

Re: [PATCH] librt: Add partial posix_spawn support

[Khem Raj]

On 02/29/2012 07:40 PM, Ismael Luceno wrote:
 
 Signed-off-by: Ismael Luceno ismael.luc...@gmail.com
 ---
  include/spawn.h|  266 
 
  librt/spawn.c  |   61 +
  librt/spawn_faction_addclose.c |   51 
  librt/spawn_faction_adddup2.c  |   52 
  librt/spawn_faction_addopen.c  |   55 
  librt/spawn_faction_init.c |   42 +++
  librt/spawn_int.h  |   29 +
  7 files changed, 556 insertions(+), 0 deletions(-)
  create mode 100644 include/spawn.h
  create mode 100644 librt/spawn.c
  create mode 100644 librt/spawn_faction_addclose.c
  create mode 100644 librt/spawn_faction_adddup2.c
  create mode 100644 librt/spawn_faction_addopen.c
  create mode 100644 librt/spawn_faction_init.c
  create mode 100644 librt/spawn_int.h

Can you please add kconfig knob for it

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

Re: [PATCH 2/2] MIPS: Fix more *_NONBLOCK definitions

[Khem Raj]

On Thu, Feb 9, 2012 at 12:16 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 I would prefer to handle this in the common file like we already do
 for e.g. signalfd.h

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

Re: [PATCH 2/2] MIPS: Fix more *_NONBLOCK definitions

[Khem Raj]

On Thu, Feb 9, 2012 at 8:49 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 On Feb 9, 2012 3:48 PM, Khem Raj raj.k...@gmail.com wrote:

 On Thu, Feb 9, 2012 at 12:16 AM, Bernhard Reutner-Fischer
 rep.dot@gmail.com wrote:
  I would prefer to handle this in the common file like we already do
  for e.g. signalfd.h

 using ifdefs ?

 Yes.

why do you think thats advantageous.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 2/2] MIPS: Fix more *_NONBLOCK definitions

[Khem Raj]

On Thu, Feb 9, 2012 at 12:53 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 See my first reply in this thread. Furthermore it is easier to keep the
 common bits in sync if they are in one header as opposed to be in 5
 different headers (like we would need for timerfd and eventfd for the
 affected arches).
 What are your concerns?

thats fine so we are treading a path where we make a decision if a
file can be overridden
or not. I guess we should document it somewhere on when to fork a file
and when to use arch specific ifdefs in common file
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: future branch

[Khem Raj]

On Wed, Feb 8, 2012 at 7:15 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 I am merging your future branch into master ATM. A couple of questions:

Bernhard

As i have said earlier currently there are regressions where X does
not start. and its hard to tell which of those 400 odd
patches are causing it. I have been actively trying to figure and
thats why all rebasing and stuff.

Some of those patches need squashing as well. I am able to compile the
rebased patchset on arm mips ppc x86 and amd64
but they do not into X. So we should merge it in parts and do squash
the commits as they need to be

Please do not rush them and then spend months figuring out regressions.

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

Re: future branch

[Khem Raj]

On Wed, Feb 8, 2012 at 8:22 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:

 Please do not rush them and then spend months figuring out regressions.

 Be asured that I will not push this right away but am rather starting to
 review and test locally.


thanks


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

Re: future branch

[Khem Raj]

On Wed, Feb 8, 2012 at 10:42 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 Core-image-sato does not build for me due to some buggy package that
 unconditionally uses *netgrp() or the like.
 Not amused, way out without going beserk?

Yeah with future branch here is my patch. git am it.

http://uclibc.org/~kraj/0001-uclibc-git-Update-to-latest-plus-future-branch.patch

apply that on master of oe-core

then set

UCLIBCVERSION = 0.9.33+gitr% in local.conf
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: future branch

[Khem Raj]

On Wed, Feb 8, 2012 at 12:17 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 Fcntl{,64} is a nightmare, yes. But your hunk does not strike me as
 immediately helpful.
 arm/ioperm hidden def removal is OK, I think, without having sources at
 hand.
 The socketcall hunk is nonsense, see my previous reply to Peter in this
 thread.

 +-# provided via pthreads builddir +-CSRC-y := $(filter-out $(libc_a_CSRC)
 $(notdir $(libpthread_libc_OBJS:.o=.c)),$(CSRC-y)) +-SSRC := $(filter-out
 $(libc_a_SSRC) $(notdir $(libpthread_libc_OBJS:.o=.S)),$(SSRC))
 Huh? Sounds inappropriate to me.
 Oh, filtering later on makes sense, so OK, good catch!

 +-ifeq ($(IS_EABI),y) ++ifeq ($(CONFIG_ARM_EABI),y)
 But _that_ is a step backwards, NACK.

yes most of my patches are cobbled up on top to get to a compiling
state so it could be
a garbage to hide another garbage
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH 2/2] MIPS: Fix more *_NONBLOCK definitions

[Khem Raj]

On Wed, Feb 8, 2012 at 10:23 PM, Kevin Cernekee cerne...@gmail.com wrote:
 On Wed, Feb 8, 2012 at 10:12 PM, Kevin Cernekee cerne...@gmail.com wrote:
 SOCK_NONBLOCK: correct
 SFD_NONBLOCK: correct (fixed in recent commit f87898ca)
 TFD_NONBLOCK: incorrect
 IN_NONBLOCK: incorrect

 Attaching the test cases I wrote to validate that these four syscalls
 work correctly on my new toolchain.

 If it looks like they might be useful, I could clean them up and
 integrate them into the uClibc testsuite.

the patch is ok.
yes testcases are good please send both the patches together i.e. test
and patch itself.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: future branch

[Khem Raj]

On Fri, Feb 3, 2012 at 5:16 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote:
 On 02/02/2012 23.04, Khem Raj wrote:
 On Thu, Feb 2, 2012 at 1:38 PM, Peter Mazinger p...@gmx.net wrote:
 they are already rebased on master here https://github.com/kraj/uClibc
 so i will start from there and if you can help in issues as we find
 that will be useful
 i want to avoid breakages

 fine, tell me about problems you encounter...

 The current tree from khem does not compile with SUPPORT_LD_DEBUG=n
 Didn't look yet which change is the culprit.

 Khem, have you left out anything from the future branch? I can compile with 
 and without the above option the future branch, haven't tested your tree...

 well. I have not left anything out intentionally. But I have to patch
 some stuff locally. I have patches around for some arches on top. It
 does compile for me with those patches applied but does not boot.

 I'll give a try on SH4... asap



I have rebased the branch on latest master

git://github.com/kraj/uClibc.git

havent tested with the latest rebase please try it out.

 ___
 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
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] stat: Use stat64 syscall if available

[Khem Raj]

On Fri, Feb 3, 2012 at 4:58 AM, Mike Frysinger vap...@gentoo.org wrote:

 might be useful to add a comment why you're calling stat64 ... because that
 fills out more fields than stat does typically

will do. I sort of mentioned in commit but will add to code comments too.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] stat: Use stat64 syscall if available

[Khem Raj]

On Fri, Feb 3, 2012 at 6:15 AM, Filippo ARCIDIACONO
filippo.arcidiac...@st.com wrote:
 What do you think to extend this fix also for lstat?

yes lstat too.

 Fstatat already call fstatat64.

 -Original Message-
 From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On
 Behalf Of Filippo ARCIDIACONO
 Sent: Friday, February 03, 2012 2:46 PM
 To: 'Khem Raj'; uclibc@uclibc.org
 Subject: RE: [PATCH] stat: Use stat64 syscall if available

 I Khem,
 This is similar what I do for fstat for similar problem.
 Just a note, the call to stat64 should be also guarded by
 __UCLIBC_HAS_LFS__?
 Something like:

 #if defined __UCLIBC_HAS_LFS__  defined __NR_stat64

  -Original Message-
  From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On
  Behalf Of Carmelo AMOROSO
  Sent: Friday, February 03, 2012 2:15 PM
  To: uclibc@uclibc.org
  Subject: Re: [PATCH] stat: Use stat64 syscall if available
 
  On 03/02/2012 13.58, Mike Frysinger wrote:
   On Thursday 02 February 2012 19:12:00 Khem Raj wrote:
   --- a/libc/sysdeps/linux/common/stat.c +++
   b/libc/sysdeps/linux/common/stat.c
  
   int stat(const char *file_name, struct stat *buf) { int result;
   +#ifdef __NR_stat64 +    struct kernel_stat64 kbuf; +    result =
   INLINE_SYSCALL(stat64, 2, file_name, kbuf); +   if (result == 0)
   { +              __xstat32_conv(kbuf, buf); +   } +#else struct
  kernel_stat
   kbuf;
  
   -        result = __syscall_stat(file_name, kbuf); +    result =
   INLINE_SYSCALL(stat, 2, file_name, kbuf); if (result == 0) {
   __xstat_conv(kbuf, buf); } +#endif return result; }
  
   might be useful to add a comment why you're calling stat64 ...
   because that fills out more fields than stat does typically -mike
  
  
  
   ___ uClibc mailing
   list uClibc@uclibc.org
   http://lists.busybox.net/mailman/listinfo/uclibc
 
  We were addressing a similar issue on fstat in these days.
  see https://bugzilla.stlinux.com/show_bug.cgi?id=16578
 
  Carmelo
  ___
  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

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

commit 549fa53225910f5341092d6647a1e3dd705b605f broke INLINE_SYSCALL_NOERR_NCS

[Khem Raj]

This commit below broke ppc and mips for me
since they assign to err specifically in
INTERNAL_SYSCALL_NCS definitions so now

commit 549fa53225910f5341092d6647a1e3dd705b605f
Author: Bernhard Reutner-Fischer rep.dot@gmail.com
Date:   Thu Jan 26 15:15:23 2012 +0100

*: silence some warnings

warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]

Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com


this is the hunk I am talking about __err declaration has been
commented out. Do you know Bernhard why ?
now any functions using _syscall_noerr0 and _syscall_noerr1 wont compile anymore
if this was just meant as a cleanup then please reinsert it since we
really need it.

diff --git a/libc/sysdeps/linux/common/bits/syscalls-common.h
b/libc/sysdeps/linux/common/bits/syscalls-common.h
index 1b84d9e..faebd1b 100644
--- a/libc/sysdeps/linux/common/bits/syscalls-common.h
+++ b/libc/sysdeps/linux/common/bits/syscalls-common.h
@@ -40,21 +40,27 @@
 /* Just like INLINE_SYSCALL(), but take a non-constant syscall (NCS)
argument */
 #ifndef INLINE_SYSCALL_NCS
 # define INLINE_SYSCALL_NCS(name, nr, args...) \
-({ \
+(__extension__ \
+ ({\
INTERNAL_SYSCALL_DECL(__err);   \
-   long __res = INTERNAL_SYSCALL_NCS(name, __err, nr, args);   \
-   if (unlikely(INTERNAL_SYSCALL_ERROR_P(__res, __err))) { \
+   (__extension__  \
+({ \
+  long __res = INTERNAL_SYSCALL_NCS(name, __err, nr, args);\
+  if (unlikely(INTERNAL_SYSCALL_ERROR_P(__res, __err))) {  \
__set_errno(INTERNAL_SYSCALL_ERRNO(__res, __err));  \
__res = -1L;\
-   }   \
-   __res;  \
-})
+  }\
+  __res;   \
+ })\
+   );  \
+  })   \
+)
 #endif
 #ifndef INLINE_SYSCALL_NOERR_NCS
 # define INLINE_SYSCALL_NOERR_NCS(name, nr, args...)   \
 ({ \
-   INTERNAL_SYSCALL_DECL(__err);   \
-   long __res = INTERNAL_SYSCALL_NCS(name, __err, nr, args);   \
+   /*INTERNAL_SYSCALL_DECL(__err);*/
 \
+   long __res = INTERNAL_SYSCALL_NCS(name, /*__err*/, nr, args);   \
__res;  \
 })
 #endif
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: commit 549fa53225910f5341092d6647a1e3dd705b605f broke INLINE_SYSCALL_NOERR_NCS

[Khem Raj]

On Fri, Feb 3, 2012 at 10:55 AM, Khem Raj raj.k...@gmail.com wrote:
 This commit below broke ppc and mips for me
 since they assign to err specifically in
 INTERNAL_SYSCALL_NCS definitions so now

here is something that fixes it

http://git.openembedded.org/openembedded-core-contrib/tree/meta/recipes-core/uclibc/uclibc-0.9.33/0001-Declare-__err-and-pass-it-to-INTERNAL_SYSCALL_NCS-so.patch?h=kraj/misc

 commit 549fa53225910f5341092d6647a1e3dd705b605f
 Author: Bernhard Reutner-Fischer rep.dot@gmail.com
 Date:   Thu Jan 26 15:15:23 2012 +0100

    *: silence some warnings

    warning: ISO C90 forbids mixed declarations and code
 [-Wdeclaration-after-statement]

    Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com


 this is the hunk I am talking about __err declaration has been
 commented out. Do you know Bernhard why ?
 now any functions using _syscall_noerr0 and _syscall_noerr1 wont compile 
 anymore
 if this was just meant as a cleanup then please reinsert it since we
 really need it.

 diff --git a/libc/sysdeps/linux/common/bits/syscalls-common.h
 b/libc/sysdeps/linux/common/bits/syscalls-common.h
 index 1b84d9e..faebd1b 100644
 --- a/libc/sysdeps/linux/common/bits/syscalls-common.h
 +++ b/libc/sysdeps/linux/common/bits/syscalls-common.h
 @@ -40,21 +40,27 @@
  /* Just like INLINE_SYSCALL(), but take a non-constant syscall (NCS)
 argument */
  #ifndef INLINE_SYSCALL_NCS
  # define INLINE_SYSCALL_NCS(name, nr, args...)                         \
 -({                                                                     \
 +(__extension__                                                         \
 + ({                                                                    \
        INTERNAL_SYSCALL_DECL(__err);                                   \
 -       long __res = INTERNAL_SYSCALL_NCS(name, __err, nr, args);       \
 -       if (unlikely(INTERNAL_SYSCALL_ERROR_P(__res, __err))) {         \
 +       (__extension__                                                  \
 +        ({                                                             \
 +          long __res = INTERNAL_SYSCALL_NCS(name, __err, nr, args);    \
 +          if (unlikely(INTERNAL_SYSCALL_ERROR_P(__res, __err))) {      \
                __set_errno(INTERNAL_SYSCALL_ERRNO(__res, __err));      \
                __res = -1L;                                            \
 -       }                                                               \
 -       __res;                                                          \
 -})
 +          }                                                            \
 +          __res;                                                       \
 +         })                                                            \
 +       );                                                              \
 +  })                                                                   \
 +)
  #endif
  #ifndef INLINE_SYSCALL_NOERR_NCS
  # define INLINE_SYSCALL_NOERR_NCS(name, nr, args...)                   \
  ({                                                                     \
 -       INTERNAL_SYSCALL_DECL(__err);                                   \
 -       long __res = INTERNAL_SYSCALL_NCS(name, __err, nr, args);       \
 +       /*INTERNAL_SYSCALL_DECL(__err);*/
         \
 +       long __res = INTERNAL_SYSCALL_NCS(name, /*__err*/, nr, args);   \
        __res;                                                          \
  })
  #endif
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH V2] lstat/stat/fstat: Use 64bit version of syscall if available

[Khem Raj]

This is needed for stat'ing loop devices  255
since otherwise kernel returns EOVERFLOW becasue
it needs st_rdev/st_dev to be larger than 16bits but
in kernel it uses __old_kernel_stat for stat
syscall which has st_rdev/st_dev as unsigned short

Add a testcase

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 libc/sysdeps/linux/common/fstat.c |   18 ++
 libc/sysdeps/linux/common/lstat.c |   19 ++-
 libc/sysdeps/linux/common/stat.c  |   18 ++
 test/stat/stat-loop256.c  |   32 
 4 files changed, 74 insertions(+), 13 deletions(-)
 create mode 100644 test/stat/stat-loop256.c

diff --git a/libc/sysdeps/linux/common/fstat.c 
b/libc/sysdeps/linux/common/fstat.c
index acc639b..4726a68 100644
--- a/libc/sysdeps/linux/common/fstat.c
+++ b/libc/sysdeps/linux/common/fstat.c
@@ -12,18 +12,28 @@
 #include sys/stat.h
 #include xstatconv.h
 
-#define __NR___syscall_fstat __NR_fstat
-static __inline__ _syscall2(int, __syscall_fstat, int, fd, struct kernel_stat 
*, buf)
-
 int fstat(int fd, struct stat *buf)
 {
int result;
+#ifdef __NR_fstat64
+   /* normal stat call has limited values for various stat elements
+* e.g. uid device major/minor etc.
+* so we use 64 variant if available
+* in order to get newer versions of stat elements
+*/
+   struct kernel_stat64 kbuf;
+   result = INLINE_SYSCALL(fstat64, 2, fd, kbuf);
+   if (result == 0) {
+   __xstat32_conv(kbuf, buf);
+   }
+#else
struct kernel_stat kbuf;
 
-   result = __syscall_fstat(fd, kbuf);
+   result = INLINE_SYSCALL(fstat, 2, fd, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
 }
 libc_hidden_def(fstat)
diff --git a/libc/sysdeps/linux/common/lstat.c 
b/libc/sysdeps/linux/common/lstat.c
index aa77447..db72d1f 100644
--- a/libc/sysdeps/linux/common/lstat.c
+++ b/libc/sysdeps/linux/common/lstat.c
@@ -12,19 +12,28 @@
 #include sys/stat.h
 #include xstatconv.h
 
-#define __NR___syscall_lstat __NR_lstat
-static __inline__ _syscall2(int, __syscall_lstat,
-   const char *, file_name, struct kernel_stat *, buf)
-
 int lstat(const char *file_name, struct stat *buf)
 {
int result;
+#ifdef __NR_lstat64
+   /* normal stat call has limited values for various stat elements
+* e.g. uid device major/minor etc.
+* so we use 64 variant if available
+* in order to get newer versions of stat elements
+*/
+   struct kernel_stat64 kbuf;
+   result = INLINE_SYSCALL(lstat64, 2, file_name, kbuf);
+   if (result == 0) {
+   __xstat32_conv(kbuf, buf);
+   }
+#else
struct kernel_stat kbuf;
 
-   result = __syscall_lstat(file_name, kbuf);
+   result = INLINE_SYSCALL(lstat, 2, file_name, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
 }
 libc_hidden_def(lstat)
diff --git a/libc/sysdeps/linux/common/stat.c b/libc/sysdeps/linux/common/stat.c
index a6ab291..829f35a 100644
--- a/libc/sysdeps/linux/common/stat.c
+++ b/libc/sysdeps/linux/common/stat.c
@@ -12,20 +12,30 @@
 #include sys/stat.h
 #include xstatconv.h
 
-#define __NR___syscall_stat __NR_stat
 #undef stat
-static __inline__ _syscall2(int, __syscall_stat,
-   const char *, file_name, struct kernel_stat *, buf)
 
 int stat(const char *file_name, struct stat *buf)
 {
int result;
+#ifdef __NR_stat64
+   /* normal stat call has limited values for various stat elements
+* e.g. uid device major/minor etc.
+* so we use 64 variant if available
+* in order to get newer versions of stat elements
+*/
+   struct kernel_stat64 kbuf;
+   result = INLINE_SYSCALL(stat64, 2, file_name, kbuf);
+   if (result == 0) {
+   __xstat32_conv(kbuf, buf);
+   }
+#else
struct kernel_stat kbuf;
 
-   result = __syscall_stat(file_name, kbuf);
+   result = INLINE_SYSCALL(stat, 2, file_name, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
 }
 libc_hidden_def(stat)
diff --git a/test/stat/stat-loop256.c b/test/stat/stat-loop256.c
new file mode 100644
index 000..14284c1
--- /dev/null
+++ b/test/stat/stat-loop256.c
@@ -0,0 +1,32 @@
+#include stdio.h
+#include unistd.h
+#include stdlib.h
+#include sys/stat.h
+int main()
+{
+struct stat statbuf;
+int ret = 0;
+char* loop255 = /dev/loop255;
+char* loop256 = /dev/loop256;
+mode_t mode = 0660;
+mknod(loop255, mode, 0x7ff);
+mknod(loop256, mode, 0x100700);
+ret = stat(loop255, statbuf);
+if(ret  0) {
+   printf(stat: Cant stat %s\n,loop255);
+   unlink(loop255);
+   exit(1);
+}
+ret = stat(loop256, statbuf);
+if(ret  0) {
+printf(stat: Cant stat %s\n,loop256);
+   unlink(loop255

Re: future branch

[Khem Raj]

On Thu, Feb 2, 2012 at 6:33 AM, Peter Mazinger p...@gmx.net wrote:
  Original-Nachricht 
 Datum: Wed, 1 Feb 2012 21:03:28 -0800
 Von: Khem Raj raj.k...@gmail.com
 An: Bernhard Reutner-Fischer rep.dot@gmail.com
 CC: Peter Mazinger p...@gmx.net, uclibc@uclibc.org
 Betreff: Re: future branch

 yes  now that .33 is released we will work on putting these patches
 in. unfortunately
 these patches need to rebase on top of master and currently my rebase
 does not boot
 so we need Peter's help to refresh them

 how do you think my help should look like? After waiting so long the rework 
 is tremendous, it is like I would restart from the beginning (from my 
 mercurial repo). Should I again clear/redo future branch or do you want me to 
 send each patch to list or apply directly to head?
 I think the last one is unacceptable for some of you.
 Waiting for opinions...

they are already rebased on master here https://github.com/kraj/uClibc
so i will start from there and if you can help in issues as we find
that will be useful
i want to avoid breakages


 Regards, Peter

 --
 Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
 belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
 ___
 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

Re: future branch

[Khem Raj]

On Thu, Feb 2, 2012 at 1:38 PM, Peter Mazinger p...@gmx.net wrote:
  they are already rebased on master here https://github.com/kraj/uClibc
  so i will start from there and if you can help in issues as we find
  that will be useful
  i want to avoid breakages
 
  fine, tell me about problems you encounter...

 The current tree from khem does not compile with SUPPORT_LD_DEBUG=n
 Didn't look yet which change is the culprit.

 Khem, have you left out anything from the future branch? I can compile with 
 and without the above option the future branch, haven't tested your tree...

well. I have not left anything out intentionally. But I have to patch
some stuff locally. I have patches around for some arches on top. It
does compile for me with those patches applied but does not boot.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] stat: Use stat64 syscall if available

[Khem Raj]

This is needed for stat'ing loop devices  255
since otherwise kernel returns EOVERFLOW becasue
it needs st_rdev/st_dev to be larger than 16bits but
in kernel it uses __old_kernel_stat for stat
syscall which has st_rdev/st_dev as unsigned short

Add a testcase

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 libc/sysdeps/linux/common/stat.c |   12 +---
 test/stat/stat-loop256.c |   32 
 2 files changed, 41 insertions(+), 3 deletions(-)
 create mode 100644 test/stat/stat-loop256.c

diff --git a/libc/sysdeps/linux/common/stat.c b/libc/sysdeps/linux/common/stat.c
index a6ab291..5850266 100644
--- a/libc/sysdeps/linux/common/stat.c
+++ b/libc/sysdeps/linux/common/stat.c
@@ -14,18 +14,24 @@
 
 #define __NR___syscall_stat __NR_stat
 #undef stat
-static __inline__ _syscall2(int, __syscall_stat,
-   const char *, file_name, struct kernel_stat *, buf)
 
 int stat(const char *file_name, struct stat *buf)
 {
int result;
+#ifdef __NR_stat64
+   struct kernel_stat64 kbuf;
+   result = INLINE_SYSCALL(stat64, 2, file_name, kbuf);
+   if (result == 0) {
+   __xstat32_conv(kbuf, buf);
+   }
+#else
struct kernel_stat kbuf;
 
-   result = __syscall_stat(file_name, kbuf);
+   result = INLINE_SYSCALL(stat, 2, file_name, kbuf);
if (result == 0) {
__xstat_conv(kbuf, buf);
}
+#endif
return result;
 }
 libc_hidden_def(stat)
diff --git a/test/stat/stat-loop256.c b/test/stat/stat-loop256.c
new file mode 100644
index 000..fad4962
--- /dev/null
+++ b/test/stat/stat-loop256.c
@@ -0,0 +1,32 @@
+#include stdio.h
+#include unistd.h
+#include stdlib.h
+#include sys/stat.h
+int main()
+{
+struct stat statbuf;
+int ret = 0;
+char* loop255 = /dev/loop255;
+char* loop256 = /dev/loop256;
+mode_t mode = 0660;
+mknod(loop255, mode, 0x7ff);
+mknod(loop256, mode, 0x100700);
+ret = stat(loop255, statbuf);
+if(ret  0) {
+   printf(stat: Cant stat %s\n,loop255);
+   unlink(loop255);
+   exit(1);
+}
+ret = stat(loop256, statbuf);
+if(ret  0) { 
+printf(stat: Cant stat %s\n,loop256); 
+   unlink(loop255);
+   unlink(loop256);
+exit(1);
+}   
+
+unlink(loop255);
+unlink(loop256);
+exit(0);
+}
+
-- 
1.7.5.4

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

Re: future branch

[Khem Raj]

yes  now that .33 is released we will work on putting these patches
in. unfortunately
these patches need to rebase on top of master and currently my rebase
does not boot
so we need Peter's help to refresh them

On Wed, Feb 1, 2012 at 3:19 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 and tacking the most obvious regressions there makes more sense
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: linux-3.2.*, iptables, linux/if_packet.h, and '__aligned_u64' compile problem

[Khem Raj]

On Fri, Jan 27, 2012 at 4:56 PM, Kevin Day thekevin...@gmail.com wrote:
 In the 3.2 linux kernel series, the structure tpacket_hdr_v1 was added
 to linux/if_packet.h.
 Inside of that structure, the following variable was defined:

 __aligned_u64   seq_num;

 While compiling iptables 1.4.12.2 on a x86_64 system with the headers
 from the said kernel installed, I get the following compile error:

 /usr/include/linux/if_packet.h:176: error: expected
 specifier-qualifier-list before '__aligned_u64'.

 According to the article here:
  http://web.archiveorange.com/archive/v/EazJNEDWPcR6tgKsiHvQ
 To solve this problem, I have to add the following to sys/types.h:

 #define __aligned_u64 __u64 __attribute__((aligned(8)))
 #define __aligned_be64 __be64 __attribute__((aligned(8)))
 #define __aligned_le64 __le64 __attribute__((aligned(8)))

 This fix seems to do the trick for me.
 Is this a valid fix and can it or a proper solution be commited upstream?

why dont include linux/types.h in your app




 --
 Kevin Day
 ___
 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

Re: kernel_types.h really needed ?

[Khem Raj]

On (23/01/12 19:26), Carmelo AMOROSO wrote:
 Folks,
 I'm wondering if we do still need to have in uclibc a version of
 kernel_types.h, any idea ?

I dont think so.

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

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

Re: 256 loop devices limit

[Khem Raj]

On Sun, Jan 22, 2012 at 5:23 AM, tom jok tomjok...@gmail.com wrote:
 Hello all,

 Long story short:
 Busybox compiled against glibc does not have 256 loop devices limit.
 Confirmed with this message:
 http://lists.busybox.net/pipermail/busybox/2010-April/072128.html
 Busybox compiled against uClibc is somehow still limited to 256 loops. You
 can create more with mknod but you wont be able to use them.

 Am i doing something wrong or it's rather an uClibc limitation?
 Any chance to raise this number in the upcoming uClibc 0.9.33 release?


Do you have FEATURE_MOUNT_LOOP_CREATE set in busybox .config

 Regards,
 Tomasz Jokiel
 ___
 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

Re: [PATCH] ldso:mips: fix symbol lookup for JUMP_SLOT and COPY relocations

[Khem Raj]

On (20/01/12 10:36), Carmelo AMOROSO wrote:
 On 20/01/2012 7.55, Khem Raj wrote:
  On Thu, Jan 19, 2012 at 6:42 AM, Carmelo AMOROSO carmelo.amor...@st.com 
  wrote:
  On 19/01/2012 15.28, Carmelo AMOROSO wrote:
  Fill properly the sym_ref fields when invoking _dl_find_hash to lookup
  symbols
  
  this did not make the segfault go away. Although this patch is ok.
  this problem is a crash in libstdc++ I did not have debug info to
  get more info but I am building an image with debug info
  
 
 I can't help with mips. As soon as you have some debug out, I can try to
 figure out where the problem is.
 
 I've looked at the change history of mips/elfinterp.c, I'm not seeing
 currently other fix than this one, but I'll keep on looking at this.

I see the problem and attached patch fixed it. Relocations on mips were
being resolved before the new module scope was added to scope map and
it was causing the libstdc++ constructors to fail to run since the
symbols were not resolved properly.

I will push the three fixes we have in this series soon unless someone
has objections

-Khem


From 09eaabe18e3abbad4e8fded447a5649372a2d204 Mon Sep 17 00:00:00 2001
From: Khem Raj raj.k...@gmail.com
Date: Sat, 21 Jan 2012 00:21:41 -0800
Subject: [PATCH] mips/libdl: Apply relocations after appending the new scope

Without this the relocations for the current shared object
are not resolved since the scope is not added to map yet

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 ldso/libdl/libdl.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/ldso/libdl/libdl.c b/ldso/libdl/libdl.c
index bc3ef8a..32afe1c 100644
--- a/ldso/libdl/libdl.c
+++ b/ldso/libdl/libdl.c
@@ -543,6 +543,12 @@ static void *do_dlopen(const char *libname, int flag)
 	 * Now we go through and look for REL and RELA records that indicate fixups
 	 * to the GOT tables.  We need to do this in reverse order so that COPY
 	 * directives work correctly */
+
+	/* Get the tail of the list */
+	for (ls = _dl_loaded_modules-symbol_scope; ls  ls-next; ls = ls-next);
+
+	/* Extend the global scope by adding the local scope of the dlopened DSO. */
+	ls-next = dyn_chain-dyn-symbol_scope;
 #ifdef __mips__
 	/*
 	 * Relocation of the GOT entries for MIPS have to be done
@@ -550,11 +556,6 @@ static void *do_dlopen(const char *libname, int flag)
 	 */
 	_dl_perform_mips_global_got_relocations(tpnt, !now_flag);
 #endif
-	/* Get the tail of the list */
-	for (ls = _dl_loaded_modules-symbol_scope; ls  ls-next; ls = ls-next);
-
-	/* Extend the global scope by adding the local scope of the dlopened DSO. */
-	ls-next = dyn_chain-dyn-symbol_scope;
 
 	if (_dl_fixup(dyn_chain, _dl_loaded_modules-symbol_scope, now_flag))
 		goto oops;
-- 
1.7.0.4

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

[PATCH] libubacktrace: Add arm implementation

[Khem Raj]

Arm has a different mechanism of getting
_Unwind_GetIP. Therefore we profile arch
specific backtrace file.

Signed-off-by: Khem Raj raj.k...@gmail.com
---
 libubacktrace/Makefile.in   |   26 --
 libubacktrace/arm/Makefile.arch |   21 
 libubacktrace/arm/backtrace.c   |  104 +++
 3 files changed, 145 insertions(+), 6 deletions(-)
 create mode 100644 libubacktrace/arm/Makefile.arch
 create mode 100644 libubacktrace/arm/backtrace.c

diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in
index b18e3e6..f675bf5 100644
--- a/libubacktrace/Makefile.in
+++ b/libubacktrace/Makefile.in
@@ -6,7 +6,7 @@
 # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
 #
 
-subdirs += libubacktrace
+subdirs += libubacktrace libubacktrace/$(TARGET_ARCH)
 
 CFLAGS-libubacktrace := -DNOT_IN_libc -DIS_IN_libubacktrace $(SSP_ALL_CFLAGS)
 
@@ -23,22 +23,36 @@ libubacktrace_FULL_NAME := libubacktrace-$(VERSION).so
 libubacktrace_DIR := $(top_srcdir)libubacktrace
 libubacktrace_OUT := $(top_builddir)libubacktrace
 
+libubacktrace_ARCH_DIR:=$(libubacktrace_DIR)/$(TARGET_ARCH)
+libubacktrace_ARCH_OUT:=$(libubacktrace_OUT)/$(TARGET_ARCH)
+
+-include $(libubacktrace_ARCH_DIR)/Makefile.arch
+
 libubacktrace_SRC-y :=
 libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c backtracesyms.c 
backtracesymsfd.c
 
+# remove generic sources, if arch specific version is present
+ifneq ($(strip $(libubacktrace_ARCH_SRC-y)),)
+libubacktrace_SRC-y := $(filter-out $(notdir 
$(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC-y))
+endif
+
 # -fasynchronous-unwind-tables is required for backtrace to work using dwarf2
 CFLAGS-backtrace.c := -fasynchronous-unwind-tables
 
+# pass common flags to arch dirs
+ifneq ($(strip $(libubacktrace_ARCH_OBJS)),)
+CFLAGS-libubacktrace/$(TARGET_ARCH)/ := $(CFLAGS-libubacktrace)
+endif
 
-libubacktrace_SRCS := $(addprefix $(libubacktrace_DIR)/,$(libubacktrace_SRC-y))
+libubacktrace_SRCS := $(patsubst 
%.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SRC-y))
 libubacktrace_OBJS := $(patsubst 
$(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.o,$(libubacktrace_SRCS))
 
 ifeq ($(DOPIC),y)
-libubacktrace-a-y := $(libubacktrace_OBJS:.o=.os)
+libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os)
 else
-libubacktrace-a-y := $(libubacktrace_OBJS)
+libubacktrace-a-y += $(libubacktrace_OBJS)
 endif
-libubacktrace-so-y := $(libubacktrace_OBJS:.o=.os)
+libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os)
 
 lib-a-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.a
 lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so
@@ -61,7 +75,7 @@ $(libubacktrace_OUT)/libubacktrace_so.a: $(libubacktrace-so-y)
$(Q)$(RM) $@
$(do_ar)
 
-$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS)
+$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) 
$(libubacktrace_ARCH_SRCS)
$(Q)$(RM) $@
$(compile-m)
 
diff --git a/libubacktrace/arm/Makefile.arch b/libubacktrace/arm/Makefile.arch
new file mode 100644
index 000..dab3637
--- /dev/null
+++ b/libubacktrace/arm/Makefile.arch
@@ -0,0 +1,21 @@
+# Makefile for uClibc (libubacktrace)
+#
+# Author: Khem Raj raj.k...@gmail.com
+
+# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
+#
+
+libubacktrace_ARCH_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c
+libubacktrace_ARCH_SRCS := $(addprefix 
$(libubacktrace_ARCH_DIR)/,$(libubacktrace_ARCH_SRC-y))
+libubacktrace_ARCH_OBJS := $(patsubst 
$(libubacktrace_ARCH_DIR)/%.c,$(libubacktrace_ARCH_OUT)/%.o,$(libubacktrace_ARCH_SRCS))
+
+ifeq ($(DOPIC),y)
+libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS:.o=.os)
+else
+libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS)
+endif
+libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.os)
+
+ifeq ($(CONFIG_ARM_EABI),y)
+LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a)
+endif
diff --git a/libubacktrace/arm/backtrace.c b/libubacktrace/arm/backtrace.c
new file mode 100644
index 000..8a18c6c
--- /dev/null
+++ b/libubacktrace/arm/backtrace.c
@@ -0,0 +1,104 @@
+/*
+ * Perform stack unwinding by using the _Unwind_Backtrace.
+ *
+ * User application that wants to use backtrace needs to be
+ * compiled with -fexceptions option and -rdynamic to get full
+ * symbols printed.
+ *
+ * Copyright (C) 2009, 2010 STMicroelectronics Ltd.
+ *
+ * Author(s): Giuseppe Cavallaro peppe.cavall...@st.com
+ * - Initial implementation for glibc
+ *
+ * Author(s): Carmelo Amoroso carmelo.amor...@st.com
+ * - Reworked for uClibc
+ *   - use dlsym/dlopen from libdl
+ *   - rewrite initialisation to not use libc_once
+ *   - make it available in static link too
+ *
+ * Author(s): Khem Raj raj.k...@gmail.com
+ * - Add arm specific implementation
+ *
+ * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
+ *
+ */
+
+#include execinfo.h
+#include dlfcn.h
+#include stdlib.h
+#include unwind.h
+#include assert.h
+#include stdio.h
+
+struct trace_arg
+{
+  void **array;
+  int cnt

Re: [PATCH] libubacktrace: Add arm implementation

[Khem Raj]

On Sat, Jan 21, 2012 at 6:47 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote:
 On 21/01/2012 15.08, Khem Raj wrote:
 Arm has a different mechanism of getting
 _Unwind_GetIP. Therefore we profile arch
 specific backtrace file.

 Signed-off-by: Khem Raj raj.k...@gmail.com
 ---
  libubacktrace/Makefile.in       |   26 --
  libubacktrace/arm/Makefile.arch |   21 
  libubacktrace/arm/backtrace.c   |  104 
 +++
  3 files changed, 145 insertions(+), 6 deletions(-)
  create mode 100644 libubacktrace/arm/Makefile.arch
  create mode 100644 libubacktrace/arm/backtrace.c

 diff --git a/libubacktrace/Makefile.in b/libubacktrace/Makefile.in
 index b18e3e6..f675bf5 100644
 --- a/libubacktrace/Makefile.in
 +++ b/libubacktrace/Makefile.in
 @@ -6,7 +6,7 @@
  # Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
  #

 -subdirs += libubacktrace
 +subdirs += libubacktrace libubacktrace/$(TARGET_ARCH)

  CFLAGS-libubacktrace := -DNOT_IN_libc -DIS_IN_libubacktrace 
 $(SSP_ALL_CFLAGS)

 @@ -23,22 +23,36 @@ libubacktrace_FULL_NAME := libubacktrace-$(VERSION).so
  libubacktrace_DIR := $(top_srcdir)libubacktrace
  libubacktrace_OUT := $(top_builddir)libubacktrace

 +libubacktrace_ARCH_DIR:=$(libubacktrace_DIR)/$(TARGET_ARCH)
 +libubacktrace_ARCH_OUT:=$(libubacktrace_OUT)/$(TARGET_ARCH)
 +
 +-include $(libubacktrace_ARCH_DIR)/Makefile.arch
 +
  libubacktrace_SRC-y :=
  libubacktrace_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c backtracesyms.c 
 backtracesymsfd.c

 +# remove generic sources, if arch specific version is present
 +ifneq ($(strip $(libubacktrace_ARCH_SRC-y)),)
 +libubacktrace_SRC-y := $(filter-out $(notdir 
 $(libubacktrace_ARCH_SRC-y)),$(libubacktrace_SRC-y))
 +endif
 +
  # -fasynchronous-unwind-tables is required for backtrace to work using 
 dwarf2
  CFLAGS-backtrace.c := -fasynchronous-unwind-tables

 +# pass common flags to arch dirs
 +ifneq ($(strip $(libubacktrace_ARCH_OBJS)),)
 +CFLAGS-libubacktrace/$(TARGET_ARCH)/ := $(CFLAGS-libubacktrace)
 +endif

 -libubacktrace_SRCS := $(addprefix 
 $(libubacktrace_DIR)/,$(libubacktrace_SRC-y))
 +libubacktrace_SRCS := $(patsubst 
 %.c,$(libubacktrace_DIR)/%.c,$(libubacktrace_SRC-y))
  libubacktrace_OBJS := $(patsubst 
 $(libubacktrace_DIR)/%.c,$(libubacktrace_OUT)/%.o,$(libubacktrace_SRCS))

  ifeq ($(DOPIC),y)
 -libubacktrace-a-y := $(libubacktrace_OBJS:.o=.os)
 +libubacktrace-a-y += $(libubacktrace_OBJS:.o=.os)
  else
 -libubacktrace-a-y := $(libubacktrace_OBJS)
 +libubacktrace-a-y += $(libubacktrace_OBJS)
  endif
 -libubacktrace-so-y := $(libubacktrace_OBJS:.o=.os)
 +libubacktrace-so-y += $(libubacktrace_OBJS:.o=.os)

  lib-a-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.a
  lib-so-$(UCLIBC_HAS_BACKTRACE) += $(top_builddir)lib/libubacktrace.so
 @@ -61,7 +75,7 @@ $(libubacktrace_OUT)/libubacktrace_so.a: 
 $(libubacktrace-so-y)
       $(Q)$(RM) $@
       $(do_ar)

 -$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS)
 +$(libubacktrace_OUT)/libubacktrace.oS: $(libubacktrace_SRCS) 
 $(libubacktrace_ARCH_SRCS)
       $(Q)$(RM) $@
       $(compile-m)

 diff --git a/libubacktrace/arm/Makefile.arch 
 b/libubacktrace/arm/Makefile.arch
 new file mode 100644
 index 000..dab3637
 --- /dev/null
 +++ b/libubacktrace/arm/Makefile.arch
 @@ -0,0 +1,21 @@
 +# Makefile for uClibc (libubacktrace)
 +#
 +# Author: Khem Raj raj.k...@gmail.com
 +
 +# Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball.
 +#
 +
 +libubacktrace_ARCH_SRC-$(UCLIBC_HAS_BACKTRACE) := backtrace.c
 +libubacktrace_ARCH_SRCS := $(addprefix 
 $(libubacktrace_ARCH_DIR)/,$(libubacktrace_ARCH_SRC-y))
 +libubacktrace_ARCH_OBJS := $(patsubst 
 $(libubacktrace_ARCH_DIR)/%.c,$(libubacktrace_ARCH_OUT)/%.o,$(libubacktrace_ARCH_SRCS))
 +
 +ifeq ($(DOPIC),y)
 +libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS:.o=.os)
 +else
 +libubacktrace-a-y+=$(libubacktrace_ARCH_OBJS)
 +endif
 +libubacktrace-so-y+=$(libubacktrace_ARCH_OBJS:.o=.os)
 +
 +ifeq ($(CONFIG_ARM_EABI),y)
 +LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a)
 +endif

 with my proposed patch to move __aeabi_unwind_cpp_pr in uclibc_shared.a
 should not be needed.

lets make this change after you have installed that patch. For now I will
keep it.


 diff --git a/libubacktrace/arm/backtrace.c b/libubacktrace/arm/backtrace.c
 new file mode 100644
 index 000..8a18c6c
 --- /dev/null
 +++ b/libubacktrace/arm/backtrace.c
 @@ -0,0 +1,104 @@
 +/*
 + * Perform stack unwinding by using the _Unwind_Backtrace.
 + *
 + * User application that wants to use backtrace needs to be
 + * compiled with -fexceptions option and -rdynamic to get full
 + * symbols printed.
 + *
 + * Copyright (C) 2009, 2010 STMicroelectronics Ltd.
 + *
 + * Author(s): Giuseppe Cavallaro peppe.cavall...@st.com
 + * - Initial implementation for glibc
 + *
 + * Author(s): Carmelo Amoroso carmelo.amor...@st.com
 + * - Reworked for uClibc
 + *   - use dlsym/dlopen from libdl
 + *   - rewrite

Re: [PATCH] libm: Export bessel functions

[Khem Raj]

On Thursday, January 19, 2012, Bernhard Reutner-Fischer 
rep.dot@gmail.com wrote:
 On 20 January 2012 08:05, Khem Raj raj.k...@gmail.com wrote:
 Currently j0,j1,jn and y0,y1 and yn
 are defined but with hidden visibility
 With this patch we export them and also
 keep a hidden alias for internal use

 They are visible for me:
 $ nm -D --def lib/libm-0.9.33-rc1-git.so | grep jn
 a1fc T jn

I am using gcc4.6 and bin utile 2.22
I dont see them

 Do you have DO_XSI_MATH=y ?

Yes


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