From vapier at uclibc.org Fri Jun 1 12:17:37 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 1 Jun 2007 12:17:37 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc/misc/internals Message-ID: <20070601191737.6BCC548571@busybox.net> Author: vapier Date: 2007-06-01 12:17:36 -0700 (Fri, 01 Jun 2007) New Revision: 18722 Log: change the auxvt code from being dependent on MMU to !LDSO as auxvt things are ELF-specific, not MMU-specific Modified: trunk/uClibc/libc/misc/internals/__uClibc_main.c Changeset: Modified: trunk/uClibc/libc/misc/internals/__uClibc_main.c =================================================================== --- trunk/uClibc/libc/misc/internals/__uClibc_main.c 2007-06-01 14:40:03 UTC (rev 18721) +++ trunk/uClibc/libc/misc/internals/__uClibc_main.c 2007-06-01 19:17:36 UTC (rev 18722) @@ -33,7 +33,7 @@ #ifdef __UCLIBC_HAS_PROGRAM_INVOCATION_NAME__ libc_hidden_proto(strrchr) #endif -#ifdef __ARCH_USE_MMU__ +#ifndef __ARCH_HAS_NO_LDSO__ libc_hidden_proto(memcpy) libc_hidden_proto(getgid) libc_hidden_proto(getuid) @@ -129,7 +129,7 @@ # define O_NOFOLLOW 0 #endif -#ifdef __ARCH_USE_MMU__ +#ifndef __ARCH_HAS_NO_LDSO__ static void __check_one_fd(int fd, int mode) { /* Check if the specified fd is already open */ @@ -277,7 +277,7 @@ char **argv, void (*app_init)(void), void (*app_fini)(void), void (*rtld_fini)(void), void *stack_end) { -#ifdef __ARCH_USE_MMU__ +#ifndef __ARCH_HAS_NO_LDSO__ unsigned long *aux_dat; ElfW(auxv_t) auxvt[AT_EGID + 1]; #endif @@ -298,7 +298,7 @@ __environ = &argv[argc]; } -#ifdef __ARCH_USE_MMU__ +#ifndef __ARCH_HAS_NO_LDSO__ /* Pull stuff from the ELF header when possible */ memset(auxvt, 0x00, sizeof(auxvt)); aux_dat = (unsigned long*)__environ; @@ -320,7 +320,7 @@ * __uClibc_init() regardless, to be sure the right thing happens. */ __uClibc_init(); -#ifdef __ARCH_USE_MMU__ +#ifndef __ARCH_HAS_NO_LDSO__ /* Make certain getpagesize() gives the correct answer */ __pagesize = (auxvt[AT_PAGESZ].a_un.a_val)? auxvt[AT_PAGESZ].a_un.a_val : PAGE_SIZE; From gkajmowi at uclibc.org Sun Jun 3 19:31:56 2007 From: gkajmowi at uclibc.org (gkajmowi at uclibc.org) Date: Sun, 3 Jun 2007 19:31:56 -0700 (PDT) Subject: svn commit: trunk/uClibc++ Message-ID: <20070604023156.8A6C848089@busybox.net> Author: gkajmowi Date: 2007-06-03 19:31:54 -0700 (Sun, 03 Jun 2007) New Revision: 18737 Log: Bump version number in preparation for release. Modified: trunk/uClibc++/Rules.mak Changeset: Modified: trunk/uClibc++/Rules.mak =================================================================== --- trunk/uClibc++/Rules.mak 2007-06-03 22:30:22 UTC (rev 18736) +++ trunk/uClibc++/Rules.mak 2007-06-04 02:31:54 UTC (rev 18737) @@ -50,7 +50,7 @@ # this stuff alone. MAJOR_VERSION:=0 MINOR_VERSION:=2 -SUBLEVEL:=2 +SUBLEVEL:=3 VERSION:=$(MAJOR_VERSION).$(MINOR_VERSION).$(SUBLEVEL) # Ensure consistent sort order, 'gcc -print-search-dirs' behavior, etc. # LC_ALL:= C From jocke at uclibc.org Mon Jun 4 15:16:55 2007 From: jocke at uclibc.org (jocke at uclibc.org) Date: Mon, 4 Jun 2007 15:16:55 -0700 (PDT) Subject: svn commit: trunk/uClibc/ldso/ldso/powerpc Message-ID: <20070604221655.25865485BD@busybox.net> Author: jocke Date: 2007-06-04 15:16:54 -0700 (Mon, 04 Jun 2007) New Revision: 18743 Log: Correct return value. Pointed out by psm. Modified: trunk/uClibc/ldso/ldso/powerpc/elfinterp.c Changeset: Modified: trunk/uClibc/ldso/ldso/powerpc/elfinterp.c =================================================================== --- trunk/uClibc/ldso/ldso/powerpc/elfinterp.c 2007-06-04 21:03:51 UTC (rev 18742) +++ trunk/uClibc/ldso/ldso/powerpc/elfinterp.c 2007-06-04 22:16:54 UTC (rev 18743) @@ -213,7 +213,7 @@ * here, so all bases should be covered. */ if (unlikely(!symbol_addr && ELF32_ST_BIND(symtab[symtab_index].st_info) != STB_WEAK)) - return -1; + return 1; } #if defined (__SUPPORT_LD_DEBUG__) old_val = *reloc_addr; From bugs at busybox.net Wed Jun 6 10:33:11 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 6 Jun 2007 10:33:11 -0700 Subject: [uClibc 0001377]: strtod() doesn't parse DBL_MIN correctly Message-ID: <5815750dc246d3636aaf9a72a8f35a23@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1377 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1377 Category: Other Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 05-31-2007 09:25 PDT Last Modified: 06-06-2007 10:33 PDT ====================================================================== Summary: strtod() doesn't parse DBL_MIN correctly Description: The strtod() function doesn't parse the DBL_MIN correctly, returning 0.0 as the value, while glibc's strtod() returns it correctly (2.225074e-308). ====================================================================== ---------------------------------------------------------------------- chmeee - 06-06-07 10:33 ---------------------------------------------------------------------- This bug is invalid, the symptom I was seeing is actually caused by something else, another bug being filed. Issue History Date Modified Username Field Change ====================================================================== 05-31-07 09:25 chmeee New Issue 05-31-07 09:25 chmeee Status new => assigned 05-31-07 09:25 chmeee Assigned To => uClibc 06-06-07 10:33 chmeee Note Added: 0002457 ====================================================================== From bugs at busybox.net Wed Jun 6 10:42:44 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 6 Jun 2007 10:42:44 -0700 Subject: [uClibc 0001382]: strtod() ERANGE not set on underflow Message-ID: <3e0141db19af97cc3beb610d48ea69b7@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1382 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1382 Category: Math Library Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-06-2007 10:42 PDT Last Modified: 06-06-2007 10:42 PDT ====================================================================== Summary: strtod() ERANGE not set on underflow Description: The Xerces test suite checks for underflow on strtod() parsing of the string +2.250738585072014e-329 Also with the negative value of this. It correctly returns 0, but does not set errno to ERANGE. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 06-06-07 10:42 chmeee New Issue 06-06-07 10:42 chmeee Status new => assigned 06-06-07 10:42 chmeee Assigned To => uClibc ====================================================================== From bugs at busybox.net Wed Jun 6 11:27:17 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 6 Jun 2007 11:27:17 -0700 Subject: [uClibc 0001377]: strtod() doesn't parse DBL_MIN correctly Message-ID: <70ce2dbb37da9de1173fbbd2d31febe9@busybox.net> The following issue has been CLOSED ====================================================================== http://busybox.net/bugs/view.php?id=1377 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1377 Category: Other Reproducibility: always Severity: minor Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 05-31-2007 09:25 PDT Last Modified: 06-06-2007 11:27 PDT ====================================================================== Summary: strtod() doesn't parse DBL_MIN correctly Description: The strtod() function doesn't parse the DBL_MIN correctly, returning 0.0 as the value, while glibc's strtod() returns it correctly (2.225074e-308). ====================================================================== ---------------------------------------------------------------------- chmeee - 06-06-07 10:33 ---------------------------------------------------------------------- This bug is invalid, the symptom I was seeing is actually caused by something else, another bug being filed. ---------------------------------------------------------------------- bernhardf - 06-06-07 11:27 ---------------------------------------------------------------------- closed as invalid upon reporter's request. Issue History Date Modified Username Field Change ====================================================================== 05-31-07 09:25 chmeee New Issue 05-31-07 09:25 chmeee Status new => assigned 05-31-07 09:25 chmeee Assigned To => uClibc 06-06-07 10:33 chmeee Note Added: 0002457 06-06-07 11:27 bernhardf Status assigned => closed 06-06-07 11:27 bernhardf Note Added: 0002458 ====================================================================== From bugs at busybox.net Wed Jun 6 11:34:10 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 6 Jun 2007 11:34:10 -0700 Subject: [uClibc 0001382]: strtod() ERANGE not set on underflow Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1382 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1382 Category: Math Library Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-06-2007 10:42 PDT Last Modified: 06-06-2007 11:34 PDT ====================================================================== Summary: strtod() ERANGE not set on underflow Description: The Xerces test suite checks for underflow on strtod() parsing of the string +2.250738585072014e-329 Also with the negative value of this. It correctly returns 0, but does not set errno to ERANGE. ====================================================================== ---------------------------------------------------------------------- bernhardf - 06-06-07 11:34 ---------------------------------------------------------------------- May i suggest that you look into libc/stdlib/_strtod.c, looks like __fp_range_check() to verify that ERANGE is also set on underflow and supbit a patch? thanks, Issue History Date Modified Username Field Change ====================================================================== 06-06-07 10:42 chmeee New Issue 06-06-07 10:42 chmeee Status new => assigned 06-06-07 10:42 chmeee Assigned To => uClibc 06-06-07 11:34 bernhardf Note Added: 0002459 ====================================================================== From bugs at busybox.net Thu Jun 7 11:33:38 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 7 Jun 2007 11:33:38 -0700 Subject: [uClibc 0001382]: strtod() ERANGE not set on underflow Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1382 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1382 Category: Math Library Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-06-2007 10:42 PDT Last Modified: 06-07-2007 11:33 PDT ====================================================================== Summary: strtod() ERANGE not set on underflow Description: The Xerces test suite checks for underflow on strtod() parsing of the string +2.250738585072014e-329 Also with the negative value of this. It correctly returns 0, but does not set errno to ERANGE. ====================================================================== ---------------------------------------------------------------------- bernhardf - 06-06-07 11:35 ---------------------------------------------------------------------- May i suggest that you look into libc/stdlib/_strtod.c, looks like __fp_range_check() to verify that ERANGE is also set on underflow and submit a patch? thanks, ---------------------------------------------------------------------- chmeee - 06-07-07 11:33 ---------------------------------------------------------------------- I'm looking into it, and did read through that function before submitting the bug report, but I'm not quite sure how to fix it without breaking strtold. I've looked through glibc's strtod(), and that detects overflow and underflow during the parse, not afterwards, and it's the same with strtold() and strtof(). I was hoping someone with better floating point skills would be able to more easily address it. Issue History Date Modified Username Field Change ====================================================================== 06-06-07 10:42 chmeee New Issue 06-06-07 10:42 chmeee Status new => assigned 06-06-07 10:42 chmeee Assigned To => uClibc 06-06-07 11:34 bernhardf Note Added: 0002459 06-06-07 11:35 bernhardf Note Edited: 0002459 06-07-07 11:33 chmeee Note Added: 0002461 ====================================================================== From bugs at busybox.net Fri Jun 8 05:33:13 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 8 Jun 2007 05:33:13 -0700 Subject: [uClibc 0001386]: 0.9.28.2 fails to build on alpha Message-ID: <4e4813e2aa719bfb5b65af953b098062@busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1386 ====================================================================== Reported By: wigyori Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1386 Category: Architecture Specific Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 06-08-2007 05:33 PDT Last Modified: 06-08-2007 05:33 PDT ====================================================================== Summary: 0.9.28.2 fails to build on alpha Description: I've tried to build an uclibc for alpha with binutils-2.17 and gcc-4.1.2, but it fails with the following errors at sem.c: make[7]: Entering directory `/store/alpha/trunk/toolchain_build_alpha/uClibc-0.9.28.2/libc/misc/sysvipc' alpha-linux-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -pipe -funit-at-a-time -fno-stack-protector -fno-builtin -nostdinc -D_LIBC -I../../../include -I. -Os -funit-at-a-time -isystem /store/alpha/trunk/staging_dir_alpha/lib/gcc/alpha-linux-uclibc/4.1.2/include -DNDEBUG -fPIC -DL_semget sem.c -c -o semget.o In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:350:1: warning: "__NR_sys_epoll_create" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:983:1: warning: this is the location of the previous definition In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:351:1: warning: "__NR_sys_epoll_ctl" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:986:1: warning: this is the location of the previous definition In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:352:1: warning: "__NR_sys_epoll_wait" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:989:1: warning: this is the location of the previous definition sem.c:66: error: expected declaration specifiers or '...' before 'semget' sem.c:66: error: expected declaration specifiers or '...' before 'key' sem.c:66: error: expected declaration specifiers or '...' before 'nsems' sem.c:66: error: expected declaration specifiers or '...' before 'semflg' sem.c:66: warning: data definition has no type or storage class sem.c:66: warning: type defaults to 'int' in declaration of '_syscall3' make[7]: *** [semget.o] Error 1 Similar error applies to compiling semctl.o (sem.c:41, _syscall4() ). ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 06-08-07 05:33 wigyori New Issue 06-08-07 05:33 wigyori Status new => assigned 06-08-07 05:33 wigyori Assigned To => uClibc ====================================================================== From bugs at busybox.net Sun Jun 10 02:25:27 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sun, 10 Jun 2007 02:25:27 -0700 Subject: [uClibc 0001386]: 0.9.28.2 fails to build on alpha Message-ID: <29f0656d9d287a2a698c4282ddcfd3ab@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1386 ====================================================================== Reported By: wigyori Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1386 Category: Architecture Specific Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 06-08-2007 05:33 PDT Last Modified: 06-10-2007 02:25 PDT ====================================================================== Summary: 0.9.28.2 fails to build on alpha Description: I've tried to build an uclibc for alpha with binutils-2.17 and gcc-4.1.2, but it fails with the following errors at sem.c: make[7]: Entering directory `/store/alpha/trunk/toolchain_build_alpha/uClibc-0.9.28.2/libc/misc/sysvipc' alpha-linux-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -pipe -funit-at-a-time -fno-stack-protector -fno-builtin -nostdinc -D_LIBC -I../../../include -I. -Os -funit-at-a-time -isystem /store/alpha/trunk/staging_dir_alpha/lib/gcc/alpha-linux-uclibc/4.1.2/include -DNDEBUG -fPIC -DL_semget sem.c -c -o semget.o In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:350:1: warning: "__NR_sys_epoll_create" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:983:1: warning: this is the location of the previous definition In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:351:1: warning: "__NR_sys_epoll_ctl" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:986:1: warning: this is the location of the previous definition In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:352:1: warning: "__NR_sys_epoll_wait" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:989:1: warning: this is the location of the previous definition sem.c:66: error: expected declaration specifiers or '...' before 'semget' sem.c:66: error: expected declaration specifiers or '...' before 'key' sem.c:66: error: expected declaration specifiers or '...' before 'nsems' sem.c:66: error: expected declaration specifiers or '...' before 'semflg' sem.c:66: warning: data definition has no type or storage class sem.c:66: warning: type defaults to 'int' in declaration of '_syscall3' make[7]: *** [semget.o] Error 1 Similar error applies to compiling semctl.o (sem.c:41, _syscall4() ). ====================================================================== ---------------------------------------------------------------------- wigyori - 06-10-07 02:25 ---------------------------------------------------------------------- Excerpt from libc/sysdeps/linux/alpha/bits/syscall.h: /* Do something very evil for now. Until we create our own syscall * macros, short circuit bits/sysnum.h and use asm/unistd.h instead */ #include So this probably won't work until these are written. Issue History Date Modified Username Field Change ====================================================================== 06-08-07 05:33 wigyori New Issue 06-08-07 05:33 wigyori Status new => assigned 06-08-07 05:33 wigyori Assigned To => uClibc 06-08-07 05:42 wigyori Issue Monitored: wigyori 06-10-07 02:25 wigyori Note Added: 0002472 ====================================================================== From bugs at busybox.net Sun Jun 10 03:02:05 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sun, 10 Jun 2007 03:02:05 -0700 Subject: [uClibc 0001386]: 0.9.28.2 fails to build on alpha Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1386 ====================================================================== Reported By: wigyori Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1386 Category: Architecture Specific Reproducibility: always Severity: block Priority: normal Status: assigned ====================================================================== Date Submitted: 06-08-2007 05:33 PDT Last Modified: 06-10-2007 03:02 PDT ====================================================================== Summary: 0.9.28.2 fails to build on alpha Description: I've tried to build an uclibc for alpha with binutils-2.17 and gcc-4.1.2, but it fails with the following errors at sem.c: make[7]: Entering directory `/store/alpha/trunk/toolchain_build_alpha/uClibc-0.9.28.2/libc/misc/sysvipc' alpha-linux-uclibc-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -pipe -funit-at-a-time -fno-stack-protector -fno-builtin -nostdinc -D_LIBC -I../../../include -I. -Os -funit-at-a-time -isystem /store/alpha/trunk/staging_dir_alpha/lib/gcc/alpha-linux-uclibc/4.1.2/include -DNDEBUG -fPIC -DL_semget sem.c -c -o semget.o In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:350:1: warning: "__NR_sys_epoll_create" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:983:1: warning: this is the location of the previous definition In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:351:1: warning: "__NR_sys_epoll_ctl" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:986:1: warning: this is the location of the previous definition In file included from ../../../include/bits/syscalls.h:11, from ../../../include/sys/syscall.h:34, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/asm/unistd.h:352:1: warning: "__NR_sys_epoll_wait" redefined In file included from ../../../include/sys/syscall.h:32, from ../../../include/syscall.h:1, from ipc.h:3, from sem.c:22: ../../../include/bits/sysnum.h:989:1: warning: this is the location of the previous definition sem.c:66: error: expected declaration specifiers or '...' before 'semget' sem.c:66: error: expected declaration specifiers or '...' before 'key' sem.c:66: error: expected declaration specifiers or '...' before 'nsems' sem.c:66: error: expected declaration specifiers or '...' before 'semflg' sem.c:66: warning: data definition has no type or storage class sem.c:66: warning: type defaults to 'int' in declaration of '_syscall3' make[7]: *** [semget.o] Error 1 Similar error applies to compiling semctl.o (sem.c:41, _syscall4() ). ====================================================================== ---------------------------------------------------------------------- wigyori - 06-10-07 02:25 ---------------------------------------------------------------------- Excerpt from libc/sysdeps/linux/alpha/bits/syscall.h: /* Do something very evil for now. Until we create our own syscall * macros, short circuit bits/sysnum.h and use asm/unistd.h instead */ #include So this probably won't work until these are written. ---------------------------------------------------------------------- wigyori - 06-10-07 03:02 ---------------------------------------------------------------------- Seems to be fixed in SVN, hangup for now. Issue History Date Modified Username Field Change ====================================================================== 06-08-07 05:33 wigyori New Issue 06-08-07 05:33 wigyori Status new => assigned 06-08-07 05:33 wigyori Assigned To => uClibc 06-08-07 05:42 wigyori Issue Monitored: wigyori 06-10-07 02:25 wigyori Note Added: 0002472 06-10-07 03:02 wigyori Note Added: 0002473 ====================================================================== From bugs at busybox.net Tue Jun 12 06:51:06 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 12 Jun 2007 06:51:06 -0700 Subject: [uClibc 0001382]: strtod() ERANGE not set on underflow Message-ID: <1603492000985022e99ed90ed290c78d@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1382 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1382 Category: Math Library Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-06-2007 10:42 PDT Last Modified: 06-12-2007 06:51 PDT ====================================================================== Summary: strtod() ERANGE not set on underflow Description: The Xerces test suite checks for underflow on strtod() parsing of the string +2.250738585072014e-329 Also with the negative value of this. It correctly returns 0, but does not set errno to ERANGE. ====================================================================== ---------------------------------------------------------------------- bernhardf - 06-06-07 11:35 ---------------------------------------------------------------------- May i suggest that you look into libc/stdlib/_strtod.c, looks like __fp_range_check() to verify that ERANGE is also set on underflow and submit a patch? thanks, ---------------------------------------------------------------------- chmeee - 06-07-07 11:33 ---------------------------------------------------------------------- I'm looking into it, and did read through that function before submitting the bug report, but I'm not quite sure how to fix it without breaking strtold. I've looked through glibc's strtod(), and that detects overflow and underflow during the parse, not afterwards, and it's the same with strtold() and strtof(). I was hoping someone with better floating point skills would be able to more easily address it. ---------------------------------------------------------------------- chmeee - 06-12-07 06:51 ---------------------------------------------------------------------- This fix seems to work, but someone with real floating point experience should verify: Index: libc/stdlib/strtod.c =================================================================== --- libc/stdlib/strtod.c (revision 2124) +++ libc/stdlib/strtod.c (working copy) @@ -506,7 +506,7 @@ __fpmax_t __XL_NPP(__strtofpmax)(const W extern void __fp_range_check(__fpmax_t y, __fpmax_t x) { if (__FPMAX_ZERO_OR_INF_CHECK(y) /* y is 0 or +/- infinity */ - && (y != 0) /* y is not 0 (could have x>0, y==0 if underflow) */ + // && (y != 0) /* y is not 0 (could have x>0, y==0 if underflow) */ && !__FPMAX_ZERO_OR_INF_CHECK(x) /* x is not 0 or +/- infinity */ ) { __set_errno(ERANGE); /* Then x is not in y's range. */ Issue History Date Modified Username Field Change ====================================================================== 06-06-07 10:42 chmeee New Issue 06-06-07 10:42 chmeee Status new => assigned 06-06-07 10:42 chmeee Assigned To => uClibc 06-06-07 11:34 bernhardf Note Added: 0002459 06-06-07 11:35 bernhardf Note Edited: 0002459 06-07-07 11:33 chmeee Note Added: 0002461 06-12-07 06:51 chmeee Note Added: 0002476 ====================================================================== From bugs at busybox.net Tue Jun 12 06:51:29 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 12 Jun 2007 06:51:29 -0700 Subject: [uClibc 0001382]: strtod() ERANGE not set on underflow Message-ID: <91decb74b12ff117821ccd3cc9439cc6@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1382 ====================================================================== Reported By: chmeee Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1382 Category: Math Library Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-06-2007 10:42 PDT Last Modified: 06-12-2007 06:51 PDT ====================================================================== Summary: strtod() ERANGE not set on underflow Description: The Xerces test suite checks for underflow on strtod() parsing of the string +2.250738585072014e-329 Also with the negative value of this. It correctly returns 0, but does not set errno to ERANGE. ====================================================================== ---------------------------------------------------------------------- bernhardf - 06-06-07 11:35 ---------------------------------------------------------------------- May i suggest that you look into libc/stdlib/_strtod.c, looks like __fp_range_check() to verify that ERANGE is also set on underflow and submit a patch? thanks, ---------------------------------------------------------------------- chmeee - 06-07-07 11:33 ---------------------------------------------------------------------- I'm looking into it, and did read through that function before submitting the bug report, but I'm not quite sure how to fix it without breaking strtold. I've looked through glibc's strtod(), and that detects overflow and underflow during the parse, not afterwards, and it's the same with strtold() and strtof(). I was hoping someone with better floating point skills would be able to more easily address it. ---------------------------------------------------------------------- chmeee - 06-12-07 06:51 ---------------------------------------------------------------------- This fix seems to work, but someone with real floating point experience should verify: Index: libc/stdlib/strtod.c =================================================================== --- libc/stdlib/strtod.c (revision 2124) +++ libc/stdlib/strtod.c (working copy) @@ -506,7 +506,7 @@ __fpmax_t __XL_NPP(__strtofpmax)(const W extern void __fp_range_check(__fpmax_t y, __fpmax_t x) { if (__FPMAX_ZERO_OR_INF_CHECK(y) /* y is 0 or +/- infinity */ - && (y != 0) /* y is not 0 (could have x>0, y==0 if underflow) */ + // && (y != 0) /* y is not 0 (could have x>0, y==0 if underflow) */ && !__FPMAX_ZERO_OR_INF_CHECK(x) /* x is not 0 or +/- infinity */ ) { __set_errno(ERANGE); /* Then x is not in y's range. */ ---------------------------------------------------------------------- chmeee - 06-12-07 06:51 ---------------------------------------------------------------------- This fix seems to work, but someone with real floating point experience should verify: Index: libc/stdlib/strtod.c =================================================================== --- libc/stdlib/strtod.c (revision XXXX) +++ libc/stdlib/strtod.c (working copy) @@ -506,7 +506,7 @@ __fpmax_t __XL_NPP(__strtofpmax)(const W extern void __fp_range_check(__fpmax_t y, __fpmax_t x) { if (__FPMAX_ZERO_OR_INF_CHECK(y) /* y is 0 or +/- infinity */ - && (y != 0) /* y is not 0 (could have x>0, y==0 if underflow) */ + // && (y != 0) /* y is not 0 (could have x>0, y==0 if underflow) */ && !__FPMAX_ZERO_OR_INF_CHECK(x) /* x is not 0 or +/- infinity */ ) { __set_errno(ERANGE); /* Then x is not in y's range. */ Issue History Date Modified Username Field Change ====================================================================== 06-06-07 10:42 chmeee New Issue 06-06-07 10:42 chmeee Status new => assigned 06-06-07 10:42 chmeee Assigned To => uClibc 06-06-07 11:34 bernhardf Note Added: 0002459 06-06-07 11:35 bernhardf Note Edited: 0002459 06-07-07 11:33 chmeee Note Added: 0002461 06-12-07 06:51 chmeee Note Added: 0002476 06-12-07 06:51 chmeee Note Added: 0002477 ====================================================================== From bugs at busybox.net Wed Jun 13 09:00:30 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 13 Jun 2007 09:00:30 -0700 Subject: [uClibc 0001391]: pthread_cond_wait() does not block thread Message-ID: <277d141e5970f315bec41ac536d93863@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1391 ====================================================================== Reported By: jovicv Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1391 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-13-2007 09:00 PDT Last Modified: 06-13-2007 09:00 PDT ====================================================================== Summary: pthread_cond_wait() does not block thread Description: I am using pthread_cond_t variables, pthread_cond_signal() and pthread_cond_wait() to block a thread execution. The problem is that pthread_cond_wait() does not block the thread execution. On my host this program works fine with glib 4.2, but not with uclibc 0.9.28.3 on my target (i386). Here is the output with pthread debugging information: # ./test 02563 : __pthread_initialize_manager: manager stack: size=8160, bos=0x80648e0, tos=0x80668c0 02563 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 02563 : pthread_create: write REQ_CREATE to manager thread 02563 : pthread_create: before suspend(self) 02564 : __pthread_manager: before poll 02564 : __pthread_manager: after poll 02564 : __pthread_manager: before __libc_read 02564 : __pthread_manager: after __libc_read, n=148 02564 : __pthread_manager: got REQ_CREATE 02564 : pthread_handle_create: cloning new_thread = 0xbf7ffe20 02564 : pthread_handle_create: new thread pid = 2565 02564 : __pthread_manager: restarting -1209801248 02563 : pthread_create: after suspend(self) 02564 : __pthread_manager: before poll 02565 : pthread_start_thread: got req msg http://busybox.net/bugs/view.php?id=0 startEthernetSend() sending 02564 : __pthread_manager: after poll 02564 : pthread_reap_children: Segmentation fault # In my program I have two threads: 1) In the 1st thread, I have: std::cout<<"startEthernetSend()"< assigned 06-13-07 09:00 jovicv Assigned To => uClibc ====================================================================== From jocke at uclibc.org Wed Jun 13 09:23:59 2007 From: jocke at uclibc.org (jocke at uclibc.org) Date: Wed, 13 Jun 2007 09:23:59 -0700 (PDT) Subject: svn commit: trunk/uClibc/libc/sysdeps/linux/sh/sys Message-ID: <20070613162359.DF19A48008@busybox.net> Author: jocke Date: 2007-06-13 09:23:59 -0700 (Wed, 13 Jun 2007) New Revision: 18817 Log: Carmelo AMOROSO writes: Hi All, this patch fixes a mismatch in ucontext struct between uClibc and kernel. In this way a signal handler installed by sigaction can access to the whole machine state correctly. This can be applied both to trunk and nptl branch Modified: trunk/uClibc/libc/sysdeps/linux/sh/sys/ucontext.h Changeset: Modified: trunk/uClibc/libc/sysdeps/linux/sh/sys/ucontext.h =================================================================== --- trunk/uClibc/libc/sysdeps/linux/sh/sys/ucontext.h 2007-06-13 12:49:46 UTC (rev 18816) +++ trunk/uClibc/libc/sysdeps/linux/sh/sys/ucontext.h 2007-06-13 16:23:59 UTC (rev 18817) @@ -87,13 +87,25 @@ /* Context to describe whole processor state. */ typedef struct { + unsigned int oldmask; + + /* CPU registers */ gregset_t gregs; + unsigned int pc; + unsigned int pr; + unsigned int sr; + unsigned int gbr; + unsigned int mach; + unsigned int macl; + +#ifdef __CONFIG_SH4__ + /* FPU registers */ fpregset_t fpregs; fpregset_t xfpregs; unsigned int fpscr; unsigned int fpul; - unsigned int macl; - unsigned int mach; + unsigned int ownedfp; +#endif } mcontext_t; /* Userlevel context. */ From bugs at busybox.net Wed Jun 13 09:41:31 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 13 Jun 2007 09:41:31 -0700 Subject: [uClibc 0001391]: pthread_cond_wait() does not block thread Message-ID: <8d1f1eae1c70379570137ec532c90c5d@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1391 ====================================================================== Reported By: jovicv Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1391 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-13-2007 09:00 PDT Last Modified: 06-13-2007 09:41 PDT ====================================================================== Summary: pthread_cond_wait() does not block thread Description: I am using pthread_cond_t variables, pthread_cond_signal() and pthread_cond_wait() to block a thread execution. The problem is that pthread_cond_wait() does not block the thread execution. On my host this program works fine with glib 4.2, but not with uclibc 0.9.28.3 on my target (i386). Here is the output with pthread debugging information: # ./test 02563 : __pthread_initialize_manager: manager stack: size=8160, bos=0x80648e0, tos=0x80668c0 02563 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 02563 : pthread_create: write REQ_CREATE to manager thread 02563 : pthread_create: before suspend(self) 02564 : __pthread_manager: before poll 02564 : __pthread_manager: after poll 02564 : __pthread_manager: before __libc_read 02564 : __pthread_manager: after __libc_read, n=148 02564 : __pthread_manager: got REQ_CREATE 02564 : pthread_handle_create: cloning new_thread = 0xbf7ffe20 02564 : pthread_handle_create: new thread pid = 2565 02564 : __pthread_manager: restarting -1209801248 02563 : pthread_create: after suspend(self) 02564 : __pthread_manager: before poll 02565 : pthread_start_thread: got req msg http://busybox.net/bugs/view.php?id=0 startEthernetSend() sending 02564 : __pthread_manager: after poll 02564 : pthread_reap_children: Segmentation fault # In my program I have two threads: 1) In the 1st thread, I have: std::cout<<"startEthernetSend()"< assigned 06-13-07 09:00 jovicv Assigned To => uClibc 06-13-07 09:41 jovicv Note Added: 0002481 ====================================================================== From bugs at busybox.net Sat Jun 16 18:22:45 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sat, 16 Jun 2007 18:22:45 -0700 Subject: [uClibc 0001394]: strsep broken in 0.9.29, works fine in 0.9.28.3 and earlier Message-ID: The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1394 ====================================================================== Reported By: ahoying Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1394 Category: Other Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-16-2007 18:22 PDT Last Modified: 06-16-2007 18:22 PDT ====================================================================== Summary: strsep broken in 0.9.29, works fine in 0.9.28.3 and earlier Description: The changes made to the strsep code have caused it, in my application, to not return NULL after it hits the last token. For instance the following code will loop forever, continuously returning the last token (1 in the example) once it has walked through the string: copyptr = "2:45:29:325:0:TEST:1"; // Just an example while ( (token[i] = strsep(©ptr, ":")) > 0 ) { ... } Earlier versions did not have this problem. I compiled uClibc with gcc 4.1.2 for i486 AMD Elan with the following options enabled in .config: TARGET_i386=y TARGET_ARCH="i386" FORCE_OPTIONS_FOR_ARCH=y CONFIG_ELAN=y TARGET_SUBARCH="" ARCH_LITTLE_ENDIAN=y ARCH_HAS_MMU=y ARCH_USE_MMU=y UCLIBC_HAS_FLOATS=y UCLIBC_HAS_FPU=y DO_C99_MATH=y KERNEL_HEADERS="/devel/usr/src/buildroot/toolchain_build_i486/linux/include" HAVE_DOT_CONFIG=y DOPIC=y HAVE_SHARED=y LDSO_LDD_SUPPORT=y LDSO_CACHE_SUPPORT=y LDSO_BASE_FILENAME="ld.so" UCLIBC_STATIC_LDCONFIG=y LDSO_RUNPATH=y UCLIBC_CTOR_DTOR=y UCLIBC_HAS_THREADS=y LINUXTHREADS_OLD=y UCLIBC_HAS_LFS=y MALLOC_STANDARD=y MALLOC_GLIBC_COMPAT=y UCLIBC_DYNAMIC_ATEXIT=y UCLIBC_SUSV3_LEGACY=y UCLIBC_SUSV3_LEGACY_MACROS=y UCLIBC_HAS_SHADOW=y UCLIBC_HAS___PROGNAME=y UNIX98PTY_ONLY=y ASSUME_DEVPTS=y UCLIBC_HAS_TM_EXTENSIONS=y UCLIBC_HAS_TZ_CACHING=y UCLIBC_HAS_TZ_FILE=y UCLIBC_HAS_TZ_FILE_READ_MANY=y UCLIBC_TZ_FILE_PATH="/etc/TZ" UCLIBC_PWD_BUFFER_SIZE=256 UCLIBC_GRP_BUFFER_SIZE=256 UCLIBC_HAS_STRING_GENERIC_OPT=y UCLIBC_HAS_STRING_ARCH_OPT=y UCLIBC_HAS_CTYPE_TABLES=y UCLIBC_HAS_CTYPE_SIGNED=y UCLIBC_HAS_CTYPE_CHECKED=y UCLIBC_HAS_WCHAR=y UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=9 UCLIBC_HAS_STDIO_BUFSIZ_4096=y UCLIBC_HAS_STDIO_BUILTIN_BUFFER_NONE=y UCLIBC_HAS_STDIO_GETC_MACRO=y UCLIBC_HAS_STDIO_PUTC_MACRO=y UCLIBC_HAS_STDIO_AUTO_RW_TRANSITION=y UCLIBC_HAS_ERRNO_MESSAGES=y UCLIBC_HAS_SIGNUM_MESSAGES=y UCLIBC_HAS_GNU_GETOPT=y UCLIBC_HAS_GNU_GETSUBOPT=y UCLIBC_HAS_REGEX=y UCLIBC_HAS_REGEX_OLD=y UCLIBC_HAS_FNMATCH=y UCLIBC_HAS_FNMATCH_OLD=y UCLIBC_HAS_FTW=y UCLIBC_HAS_GLOB=y SHARED_LIB_LOADER_PREFIX="/lib" RUNTIME_PREFIX="/" DEVEL_PREFIX="/usr/" UCLIBC_HAS_ARC4RANDOM=y UCLIBC_BUILD_RELRO=y UCLIBC_BUILD_NOEXECSTACK=y CROSS_COMPILER_PREFIX="" UCLIBC_EXTRA_CFLAGS="" DOSTRIP=y WARNINGS="-Wall" ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 06-16-07 18:22 ahoying New Issue 06-16-07 18:22 ahoying Status new => assigned 06-16-07 18:22 ahoying Assigned To => uClibc ====================================================================== From bugs at busybox.net Tue Jun 19 20:10:29 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 19 Jun 2007 20:10:29 -0700 Subject: [uClibc 0000885]: arc4random in mktemp Message-ID: <893044db2a1afbfee14a2f0b42c8037b@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=885 ====================================================================== Reported By: ashes Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 885 Category: Security Reproducibility: N/A Severity: feature Priority: normal Status: assigned ====================================================================== Date Submitted: 05-29-2006 02:58 PDT Last Modified: 06-19-2007 20:10 PDT ====================================================================== Summary: arc4random in mktemp Description: I have attached a patch to configure mktemp(3) to use the arc4random function. While I was at it I fixed some of the SSP grammar. ====================================================================== ---------------------------------------------------------------------- ashes - 06-05-06 21:44 ---------------------------------------------------------------------- I uploaded too soon, again. Please wait while I go noodle with a new patch. I have #ifdef'd around inlining problems with gcc3 and arc4random.c; added ifdefs to make arc4random.c portable to uClibc, glibc, and standalone; and added all kinds of menu options for erandom. I made menu choice options to give priority's to /dev/erandom and sysctl erandom in case both are enabled; and another choice option for mktemp in case both /dev/erandom and arc4random are enabled. I've also decided to eliminate the sysctl loop for erandom (which you may or may not remember in the old ssp.c), in light of a new erandom kernel patch which provides 256 byte values (instead of 16 byte). This saves multiple sysctl calls. I also want to verify intel-cc is happy with arc4random.c. ---------------------------------------------------------------------- ashes - 06-19-07 20:10 ---------------------------------------------------------------------- So anyway. Attached is an updated patch. Uses a character array now, with better use of uninitialized variables if it comes down to that. Nicer copyright, from upstream. Added a manual page and a simple test. -Wall -Wformat=2 -W -Wextra gcc41 friendly. There is a new function __arc4_getbyte(), commented out, which is being used by openbsd in malloc.c. It may not be very useless in Linux, because openbsd depends solely on sysctl arandom for entropy, while in Linux sysctl is being phased out of kernel26 so we need to use /dev/urandom and use backup routines if we're in a chroot. So.. __arc4_getbyte() might be too heavy for malloc(), in Linux. I also added a config option to not use /dev/urandom, for headless systems. Issue History Date Modified Username Field Change ====================================================================== 05-29-06 02:58 ashes New Issue 05-29-06 02:58 ashes Status new => assigned 05-29-06 02:58 ashes Assigned To => uClibc 05-29-06 02:58 ashes File Added: uClibc-20060529-arc4_mktemp-1.patch 05-29-06 03:00 ashes Issue Monitored: ashes 06-05-06 21:44 ashes Note Added: 0001404 06-19-07 20:09 ashes File Added: uClibc-20070619-arc4.diff 06-19-07 20:10 ashes Note Added: 0002490 ====================================================================== From vapier at uclibc.org Fri Jun 22 00:11:54 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 22 Jun 2007 00:11:54 -0700 (PDT) Subject: svn commit: trunk/uClibc Message-ID: <20070622071154.87F774864E@busybox.net> Author: vapier Date: 2007-06-22 00:11:53 -0700 (Fri, 22 Jun 2007) New Revision: 18891 Log: pull from Blackfin repo: add -mid-shared-library for UCLIBC_FORMAT_SHARED_FLAT and -msep-data for UCLIBC_FORMAT_FLAT_SEP_DATA Modified: trunk/uClibc/Rules.mak Changeset: Modified: trunk/uClibc/Rules.mak =================================================================== --- trunk/uClibc/Rules.mak 2007-06-21 22:14:55 UTC (rev 18890) +++ trunk/uClibc/Rules.mak 2007-06-22 07:11:53 UTC (rev 18891) @@ -153,11 +153,11 @@ OPTIMIZATION+=$(call check_gcc,-fno-strength-reduce,) endif -ifeq ($(UCLIBC_FORMAT_FDPIC_ELF),y) - PICFLAG:=-mfdpic -else - PICFLAG:=-fPIC -endif +CPU_CFLAGS-$(UCLIBC_FORMAT_SHARED_FLAT) += -mid-shared-library +CPU_CFLAGS-$(UCLIBC_FORMAT_FLAT_SEP_DATA) += -msep-data + +PICFLAG-y := -fPIC +PICFLAG-$(UCLIBC_FORMAT_FDPIC_ELF) := -mfdpic PIEFLAG_NAME:=-fPIE # Some nice CPU specific optimizations From vapier at uclibc.org Fri Jun 22 09:00:48 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 22 Jun 2007 09:00:48 -0700 (PDT) Subject: svn commit: trunk/uClibc Message-ID: <20070622160048.1AAF14866B@busybox.net> Author: vapier Date: 2007-06-22 09:00:45 -0700 (Fri, 22 Jun 2007) New Revision: 18894 Log: as noted by psm, make sure we accumulate PICFLAG-y back into PICFLAG Modified: trunk/uClibc/Rules.mak Changeset: Modified: trunk/uClibc/Rules.mak =================================================================== --- trunk/uClibc/Rules.mak 2007-06-22 10:42:07 UTC (rev 18893) +++ trunk/uClibc/Rules.mak 2007-06-22 16:00:45 UTC (rev 18894) @@ -158,6 +158,7 @@ PICFLAG-y := -fPIC PICFLAG-$(UCLIBC_FORMAT_FDPIC_ELF) := -mfdpic +PICFLAG := $(PICFLAG-y) PIEFLAG_NAME:=-fPIE # Some nice CPU specific optimizations From aldot at uclibc.org Sun Jun 24 10:23:55 2007 From: aldot at uclibc.org (aldot at uclibc.org) Date: Sun, 24 Jun 2007 10:23:55 -0700 (PDT) Subject: svn commit: trunk/uClibc: include libc/sysdeps/linux/i386/bits Message-ID: <20070624172355.A00C0A45BA@busybox.net> Author: aldot Date: 2007-06-24 10:23:54 -0700 (Sun, 24 Jun 2007) New Revision: 18907 Log: - make sure to define _LIBC in libc-symbols.h before including anything else. - internal_function is only used inside libc, so do not define it in uClibc_arch_features.h on i386 if we are outside of libc. Modified: trunk/uClibc/include/libc-symbols.h trunk/uClibc/libc/sysdeps/linux/i386/bits/uClibc_arch_features.h Changeset: Modified: trunk/uClibc/include/libc-symbols.h =================================================================== --- trunk/uClibc/include/libc-symbols.h 2007-06-24 14:38:06 UTC (rev 18906) +++ trunk/uClibc/include/libc-symbols.h 2007-06-24 17:23:54 UTC (rev 18907) @@ -22,6 +22,16 @@ #ifndef _LIBC_SYMBOLS_H #define _LIBC_SYMBOLS_H 1 +/* This is defined for the compilation of all C library code. features.h + tests this to avoid inclusion of stubs.h while compiling the library, + before stubs.h has been generated. Some library code that is shared + with other packages also tests this symbol to see if it is being + compiled as part of the C library. We must define this before including + config.h, because it makes some definitions conditional on whether libc + itself is being compiled, or just some generator program. */ +#define _LIBC 1 + + /* This file's macros are included implicitly in the compilation of every file in the C library by -imacros. @@ -40,16 +50,6 @@ #include - -/* This is defined for the compilation of all C library code. features.h - tests this to avoid inclusion of stubs.h while compiling the library, - before stubs.h has been generated. Some library code that is shared - with other packages also tests this symbol to see if it is being - compiled as part of the C library. We must define this before including - config.h, because it makes some definitions conditional on whether libc - itself is being compiled, or just some generator program. */ -#define _LIBC 1 - /* Enable declarations of GNU extensions, since we are compiling them. */ #define _GNU_SOURCE 1 Modified: trunk/uClibc/libc/sysdeps/linux/i386/bits/uClibc_arch_features.h =================================================================== --- trunk/uClibc/libc/sysdeps/linux/i386/bits/uClibc_arch_features.h 2007-06-24 14:38:06 UTC (rev 18906) +++ trunk/uClibc/libc/sysdeps/linux/i386/bits/uClibc_arch_features.h 2007-06-24 17:23:54 UTC (rev 18907) @@ -42,6 +42,8 @@ /* define if target supports IEEE signed zero floats */ #define __UCLIBC_HAVE_SIGNED_ZERO__ +#if defined _LIBC #define internal_function __attribute__ ((regparm (3), stdcall)) +#endif #endif /* _BITS_UCLIBC_ARCH_FEATURES_H */ From bugs at busybox.net Mon Jun 25 17:22:36 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Mon, 25 Jun 2007 17:22:36 -0700 Subject: [uClibc 0001403]: printf and anything using vfprintf() hangs system Message-ID: <701abb5484988263d1f6969991117b06@bugs.busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1403 ====================================================================== Reported By: bjdooks Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1403 Category: Stdio Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-25-2007 17:22 PDT Last Modified: 06-25-2007 17:22 PDT ====================================================================== Summary: printf and anything using vfprintf() hangs system Description: Any function using vfprintf, such as printf and snprintf cause the system to stop. A test program shows that stdout is functional, as fwrite() to stdout will display messages on the console ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 06-25-07 17:22 bjdooks New Issue 06-25-07 17:22 bjdooks Status new => assigned 06-25-07 17:22 bjdooks Assigned To => uClibc ====================================================================== From bugs at busybox.net Mon Jun 25 17:26:44 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Mon, 25 Jun 2007 17:26:44 -0700 Subject: [uClibc 0001403]: printf and anything using vfprintf() hangs system Message-ID: <02702b1113fec32f8a98c3d530e7e5d1@bugs.busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1403 ====================================================================== Reported By: bjdooks Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1403 Category: Stdio Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-25-2007 17:22 PDT Last Modified: 06-25-2007 17:26 PDT ====================================================================== Summary: printf and anything using vfprintf() hangs system Description: Any function using vfprintf, such as printf and snprintf cause the system to stop. A test program shows that stdout is functional, as fwrite() to stdout will display messages on the console ====================================================================== ---------------------------------------------------------------------- bjdooks - 06-25-07 17:26 ---------------------------------------------------------------------- The bug is still present in the development snapshot Issue History Date Modified Username Field Change ====================================================================== 06-25-07 17:22 bjdooks New Issue 06-25-07 17:22 bjdooks Status new => assigned 06-25-07 17:22 bjdooks Assigned To => uClibc 06-25-07 17:26 bjdooks Note Added: 0002514 ====================================================================== From bugs at busybox.net Tue Jun 26 05:03:14 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Tue, 26 Jun 2007 05:03:14 -0700 Subject: [uClibc 0001403]: printf and anything using vfprintf() hangs system Message-ID: <791a4ac3fb483e4710cc571c2e954510@bugs.busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1403 ====================================================================== Reported By: bjdooks Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1403 Category: Stdio Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-25-2007 17:22 PDT Last Modified: 06-26-2007 05:03 PDT ====================================================================== Summary: printf and anything using vfprintf() hangs system Description: Any function using vfprintf, such as printf and snprintf cause the system to stop. A test program shows that stdout is functional, as fwrite() to stdout will display messages on the console ====================================================================== ---------------------------------------------------------------------- bjdooks - 06-25-07 17:26 ---------------------------------------------------------------------- The bug is still present in the development snapshot ---------------------------------------------------------------------- bjdooks - 06-26-07 05:03 ---------------------------------------------------------------------- Building gcc 4.1.2 for OABI (patches will be sent in seperate report) does not work either. Issue History Date Modified Username Field Change ====================================================================== 06-25-07 17:22 bjdooks New Issue 06-25-07 17:22 bjdooks Status new => assigned 06-25-07 17:22 bjdooks Assigned To => uClibc 06-25-07 17:26 bjdooks Note Added: 0002514 06-26-07 05:03 bjdooks Note Added: 0002517 ====================================================================== From bugs at busybox.net Wed Jun 27 12:59:00 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 27 Jun 2007 12:59:00 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 06-27-2007 12:58 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 ====================================================================== From bugs at busybox.net Wed Jun 27 13:15:55 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 27 Jun 2007 13:15:55 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: <379cd8870fe2dd1eb40aa95d48fda132@bugs.uclibc.org> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 06-27-2007 13:15 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 ====================================================================== From bugs at busybox.net Wed Jun 27 13:26:03 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 27 Jun 2007 13:26:03 -0700 Subject: [uClibc 0001013]: pthread_cancel/pthread_join sequence hangs when using select in an other thread Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1013 ====================================================================== Reported By: jalaber Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1013 Category: Posix Threads Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 08-31-2006 09:04 PDT Last Modified: 06-27-2007 13:26 PDT ====================================================================== Summary: pthread_cancel/pthread_join sequence hangs when using select in an other thread Description: Hello, I have found a very strange bug in uClibc using pthread_cancel/pthread_join. My test program launches 1 thread which basically makes a select call with a struct timeval set to 600ms. Then the main thread calls pthread_cancel and pthread_join, followed by a printf. The program hangs. However if you remove the printf call, then the program terminates normally. I have tried to replace the select call with a sem_wait call, and everything works fine with or without printf. So the problem seems to happen only with select. I use buildroot with kernel 2.4.28 and uclibc 0.9.28. I have attached the program to reproduce. If you try to comment the printf("join OK\n"), it works for me. Thank you for your time and help, Philippe. ====================================================================== ---------------------------------------------------------------------- dwagner - 10-23-06 11:43 ---------------------------------------------------------------------- I think this issue is responsible that the LIRC driver of directfb RC1 does not terminate. The driver uses select() and pthread_cancel()/pthread_join(). Please fix that. ---------------------------------------------------------------------- vapier - 11-16-06 23:07 ---------------------------------------------------------------------- here's a tip ... saying things like "Please fix that." makes people think "Fix it your goddamn self." the hang may be because of the IO mutex being held by the canceled thread ... if you turn on PDEBUG in libpthread/linuxthreads/debug.h, that may give you helpful output ---------------------------------------------------------------------- chombourger - 06-27-07 12:58 ---------------------------------------------------------------------- I tried to reproduce this issue on uclibc 0.9.29 running on a PC with a 2.6 linux kernel and your program is still running as I am typing these lines! Is it what you are getting? Running the same program on the host (compiled and linked against glibc worked). I will now try to enable the debug traces to see if that helps. ---------------------------------------------------------------------- chombourger - 06-27-07 13:15 ---------------------------------------------------------------------- traces with debug enabled in linuxthreads.old: 26294 : __pthread_initialize_manager: manager stack: size=8160, bos=0x804a150, tos=0x804c130 26294 : __pthread_initialize_manager: send REQ_DEBUG to manager thread 26294 : pthread_create: write REQ_CREATE to manager thread 26294 : pthread_create: before suspend(self) 26295 : __pthread_manager: before poll 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before __libc_read 26295 : __pthread_manager: after __libc_read, n=148 26295 : __pthread_manager: got REQ_CREATE 26295 : pthread_handle_create: cloning new_thread = 0xbf1ffe20 26295 : pthread_handle_create: new thread pid = 26296 26295 : __pthread_manager: restarting -1208466944 26294 : pthread_create: after suspend(self) 26295 : __pthread_manager: before poll 26296 : pthread_start_thread: step 0 step 1 step 2 26295 : __pthread_manager: after poll 26295 : __pthread_manager: before poll step 3 cancel th... 26294 : pthread_cancel: sending cancel signal to 26296 26294 : pthread_cancel: kill returned 0 ---------------------------------------------------------------------- chombourger - 06-27-07 13:26 ---------------------------------------------------------------------- It seems that the created thread has no jmpbuf when pthread_handle_sigcancel() is called in the created thread and the signal handler returns and the thread was not rerouted. Issue History Date Modified Username Field Change ====================================================================== 08-31-06 09:04 jalaber New Issue 08-31-06 09:04 jalaber Status new => assigned 08-31-06 09:04 jalaber Assigned To => uClibc 08-31-06 09:04 jalaber File Added: pthread_join_test.c 10-23-06 11:41 dwagner Issue Monitored: dwagner 10-23-06 11:43 dwagner Note Added: 0001715 11-16-06 23:07 vapier Note Added: 0001744 06-27-07 12:58 chombourger Note Added: 0002526 06-27-07 13:15 chombourger Note Added: 0002527 06-27-07 13:26 chombourger Note Added: 0002528 ====================================================================== From bugs at busybox.net Wed Jun 27 14:25:24 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Wed, 27 Jun 2007 14:25:24 -0700 Subject: [uClibc 0001164]: libgfortran build crashes with uClibc and gcc 4.2 Message-ID: <497064cc6d006a5309d5a9fd13613455@bugs.busybox.net> The following issue has been CLOSED ====================================================================== http://busybox.net/bugs/view.php?id=1164 ====================================================================== Reported By: linux_junkie Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1164 Category: Shared Library Support Reproducibility: always Severity: crash Priority: normal Status: closed Resolution: open Fixed in Version: ====================================================================== Date Submitted: 01-17-2007 22:32 PST Last Modified: 06-27-2007 14:25 PDT ====================================================================== Summary: libgfortran build crashes with uClibc and gcc 4.2 Description: When building with buildroot and the latest gcc snapshot the build crashes: Checking multilib configuration for libgfortran... make[3]: Entering directory `/root/buildroot/toolchain_build_i686/gcc-4.2-final/i686-linux-uclibc/libgfortran' /bin/sh /root/buildroot/toolchain_build_i686/gcc-4.2-20070110/libgfortran/mk-kinds-h.sh '/root/buildroot/toolchain_build_i686/gcc-4.2-final/./gcc/gfortran -B/root/buildroot/toolchain_build_i686/gcc-4.2-final/./gcc/ -B/root/buildroot/build_i686/staging_dir/i686-linux-uclibc/bin/ -B/root/buildroot/build_i686/staging_dir/i686-linux-uclibc/lib/ -isystem /root/buildroot/build_i686/staging_dir/i686-linux-uclibc/include -isystem /root/buildroot/build_i686/staging_dir/i686-linux-uclibc/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h /root/buildroot/toolchain_build_i686/gcc-4.2-20070110/libgfortran/mk-kinds-h.sh: Unknown type grep '^#' < kinds.h > kinds.inc /bin/sh: kinds.h: No such file or directory make[3]: *** [kinds.inc] Error 1 make[3]: Leaving directory `/root/buildroot/toolchain_build_i686/gcc-4.2-final/i686-linux-uclibc/libgfortran' make[2]: *** [all-target-libgfortran] Error 2 make[2]: Leaving directory `/root/buildroot/toolchain_build_i686/gcc-4.2-final' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/buildroot/toolchain_build_i686/gcc-4.2-final' make: *** [/root/buildroot/toolchain_build_i686/gcc-4.2-final/.compiled] Error 2 [root at builder buildroot]# Is this a problem with libgfortran?? I found this thread: http://gcc.gnu.org/ml/gcc-bugs/2006-03/msg00484.html and it seems to indicates this is a problem with GMP and MPFR?? Is this so and how do I fix it? ====================================================================== ---------------------------------------------------------------------- bernhardf - 01-18-07 14:10 ---------------------------------------------------------------------- I'm aware of this glitch. Give me some time to get my gmp/mpfr build-changes merged back. Meanwhile, please do these two things: 1) Attach you toplevel .config and the uclibc.config you use, specify what compiler/binutils/gmp/mpfr version you have on your build-host. 2) Use the most current daily snapshot (or a current checkout of the gcc-4_2-branch) of gcc-4.2 and let me know what *exact* version you were experiencing this error with. As a quick stopper, read the thread at: http://gcc.gnu.org/ml/fortran/2006-10/msg00136.html and eventually apply that dirty hack to bail out if the kinds were mis-detected. Tracking down an exact setup on where we can reproduce this failure is very much appreciated! Thanks and kind regards, ---------------------------------------------------------------------- linux_junkie - 01-19-07 14:37 ---------------------------------------------------------------------- My build-host is just the generic buildroot image from the website. I am trying to use this to build a more updated development system that I can boot too. The generic buildroot image is for the old 2.4 kernel. I have uploaded the bildroot .config file and the uClibc .config file. The versions building are: binutils-2.17.50.0.8.tar.bz2 uClibc-snapshot.tar.bz2 (0.9.29) gcc-4.2-20070110.tar.bz2 gmp-4.2.1.tar.bz2 mpfr-2.2.1.tar.bz2 linux-2.6.19.2.tar.bz2 ---------------------------------------------------------------------- linux_junkie - 01-24-07 20:22 ---------------------------------------------------------------------- Just wanted to note I was able to build sucessfully with out the fortran compiler checked off. This means the problem may be within the fortran package. ---------------------------------------------------------------------- bernhardf - 06-27-07 14:25 ---------------------------------------------------------------------- This was fixed quite some time ago. Issue History Date Modified Username Field Change ====================================================================== 01-17-07 22:32 linux_junkie New Issue 01-17-07 22:32 linux_junkie Status new => assigned 01-17-07 22:32 linux_junkie Assigned To => uClibc 01-17-07 22:35 linux_junkie Issue Monitored: linux_junkie 01-18-07 14:10 bernhardf Note Added: 0001992 01-19-07 14:25 linux_junkie File Added: buildroot_config 01-19-07 14:26 linux_junkie File Added: uclibc_config 01-19-07 14:37 linux_junkie Note Added: 0002009 01-24-07 20:22 linux_junkie Note Added: 0002043 06-27-07 14:25 bernhardf Status assigned => closed 06-27-07 14:25 bernhardf Note Added: 0002529 ====================================================================== From bugs at busybox.net Thu Jun 28 05:31:01 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Thu, 28 Jun 2007 05:31:01 -0700 Subject: [uClibc 0001407]: gen_wctype segmentation fault Message-ID: <26c6fde1cf927fe493ea117c20d9aca8@bugs.uclibc.org> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1407 ====================================================================== Reported By: cmachine Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1407 Category: Architecture Specific Reproducibility: always Severity: minor Priority: normal Status: assigned ====================================================================== Date Submitted: 06-28-2007 05:31 PDT Last Modified: 06-28-2007 05:31 PDT ====================================================================== Summary: gen_wctype segmentation fault Description: Log: ./gen_wctype en_US gen_collate.c:1461:2: warning: #warning need to update last in order and position or check gen_collate.c:1547:2: warning: #warning devel code gen_collate.c:1690:2: warning: #warning devel code gen_collate.c:1811:2: warning: #warning need to add section to weight list? gen_collate.c:1891:2: warning: #warning have to use rule for current section!!! gen_collate.c:1942:2: warning: #warning devel code gen_collate.c:1945:2: warning: #warning hack to get around hu_HU reorder-after problem gen_collate.c:2352:2: warning: #warning devel code gen_collate.c: In function 'dump_section': gen_collate.c:2466: warning: unused variable 'i' gen_collate.c:2618:2: warning: #warning fix the index2weight check!! gen_collate.c:2655:2: warning: #warning check ko_kR and 9 gen_collate.c:2662:2: warning: #warning check ko_kR and 9 gen_collate.c:2686:2: warning: #warning check ko_kR and 9 gen_collate.c:2708:2: warning: #warning check gen_collate.c:3193:2: warning: #warning handle UNDEFINED idx specially? what if in only some of derived? gen_collate.c: In function 'finalize_base': gen_collate.c:2601: warning: unused variable 'n' gen_collate.c:2600: warning: unused variable 'p' gen_collate.c: In function 'print_starter_all_node': gen_collate.c:3253: warning: unused variable 'x' gen_collate.c:3252: warning: unused variable 'n' gen_collate.c:3251: warning: unused variable 'p' gen_collate.c:3250: warning: unused variable 'ci' typecount[ 0] = 95084 C_unclassified typecount[ 1] = 88837 C_alpha_nonupper_nonlower typecount[ 2] = 756 C_alpha_lower typecount[ 3] = 4 C_alpha_upper_lower typecount[ 4] = 745 C_alpha_upper typecount[ 5] = 10 C_digit typecount[ 6] = 11088 C_punct typecount[ 7] = 2 C_graph typecount[ 8] = 0 C_print_space_nonblank typecount[ 9] = 15 C_print_space_blank typecount[10] = 0 C_space_nonblank_noncntrl typecount[11] = 0 C_space_blank_noncntrl typecount[12] = 6 C_cntrl_space_nonblank typecount[13] = 1 C_cntrl_space_blank typecount[14] = 60 C_cntrl_nonspace typecount[15] = 0 empty_slot optimizing is* table.. gen_collate.c: In function 'add_rule': gen_collate.c:3638: warning: unused variable 'j' gen_collate.c: In function 'add_range_rule': gen_collate.c:3715: warning: unused variable 'j' gen_collate.c: In function 'dump_collate': gen_collate.c:3939: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int' gen_collate.c: At top level: gen_collate.c:3792: warning: 'dump_base_locale' defined but not used gen_collate.c:3828: warning: 'dump_der_locale' defined but not used gen_collate.c:850: warning: 'print_colnode' defined but not used gen_collate.c:2584: warning: 'print_starter_node' defined but not used gen_collate.c:3248: warning: 'print_starter_all_node' defined but not used ishift 1 tshift 0 size 49441 ishift 2 tshift 0 size 25561 ishift 3 tshift 0 size 14365 ishift 4 tshift 0 size 9845 ishift 5 tshift 0 size 8453 ishift 6 tshift 0 size 7909 ishift 1 tshift 1 size 25302 ishift 2 tshift 1 size 13560 ishift 3 tshift 1 size 8228 ishift 4 tshift 1 size 5996 ishift 5 tshift 1 size 4956 ishift 6 tshift 1 size 4796 ishift 1 tshift 2 size 13746 ishift 2 tshift 2 size 8008 ishift 3 tshift 2 size 5356 ishift 4 tshift 2 size 4068 ishift 5 tshift 2 size 3604 ishift 1 tshift 3 size 8642 ishift 2 tshift 3 size 5780 ishift 3 tshift 3 size 4368 ishift 4 tshift 3 size 3752 ishift 5 tshift 3 size 3704 ishift 1 tshift 4 size 7070 ishift 2 tshift 4 size 5596 ishift 3 tshift 4 size 4904 ishift 4 tshift 4 size 4688 ishift 1 tshift 5 size 7078 ishift 2 tshift 5 size 6348 ishift 3 tshift 5 size 6048 ishift 4 tshift 5 size 5984 ishift 1 tshift 6 size 7222 ishift 2 tshift 6 size 6880 ishift 3 tshift 6 size 6752 ishift 4 tshift 6 size 6752 ishift 1 tshift 7 size 8016 ishift 2 tshift 7 size 7856 ishift 3 tshift 7 size 7808 ishift 1 tshift 8 size 10488 ishift 2 tshift 8 size 10416 ishift 3 tshift 8 size 10416 ishift 1 tshift 9 size 14472 ishift 2 tshift 9 size 14448 ishift 1 tshift 10 size 20560 ishift 2 tshift 10 size 20556 smallest = 3604 setting ishift 5 tshift 2 make: *** [wctables.h] &http://busybox.net/bugs/view.php?id=1054;&http://busybox.net/bugs/view.php?id=1096;&http://busybox.net/bugs/view.php?id=1080;&http://busybox.net/bugs/view.php?id=1073;&http://busybox.net/bugs/view.php?id=1082;&http://busybox.net/bugs/view.php?id=1072; &http://busybox.net/bugs/view.php?id=1089;&http://busybox.net/bugs/view.php?id=1077;&http://busybox.net/bugs/view.php?id=1075;&http://busybox.net/bugs/view.php?id=1084;&http://busybox.net/bugs/view.php?id=1077;&http://busybox.net/bugs/view.php?id=1085;&http://busybox.net/bugs/view.php?id=1090;&http://busybox.net/bugs/view.php?id=1080;&http://busybox.net/bugs/view.php?id=1088;&http://busybox.net/bugs/view.php?id=1086;&http://busybox.net/bugs/view.php?id=1074;&http://busybox.net/bugs/view.php?id=1072;&http://busybox.net/bugs/view.php?id=1085;&http://busybox.net/bugs/view.php?id=1080;&http://busybox.net/bugs/view.php?id=1103; (core dumped) make: *** Waiting for unfinished jobs.... ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 06-28-07 05:31 cmachine New Issue 06-28-07 05:31 cmachine Status new => assigned 06-28-07 05:31 cmachine Assigned To => uClibc 06-28-07 05:31 cmachine File Added: uclibc-0.9.28.3-get_wctype.patch ====================================================================== From vapier at uclibc.org Fri Jun 29 01:19:23 2007 From: vapier at uclibc.org (vapier at uclibc.org) Date: Fri, 29 Jun 2007 01:19:23 -0700 (PDT) Subject: svn commit: trunk/uClibc/libpthread/linuxthreads.old Message-ID: <20070629081923.80DA5A60F0@busybox.net> Author: vapier Date: 2007-06-29 01:19:22 -0700 (Fri, 29 Jun 2007) New Revision: 18970 Log: tweak msync prototype to match header Modified: trunk/uClibc/libpthread/linuxthreads.old/wrapsyscall.c Changeset: Modified: trunk/uClibc/libpthread/linuxthreads.old/wrapsyscall.c =================================================================== --- trunk/uClibc/libpthread/linuxthreads.old/wrapsyscall.c 2007-06-29 08:18:13 UTC (rev 18969) +++ trunk/uClibc/libpthread/linuxthreads.old/wrapsyscall.c 2007-06-29 08:19:22 UTC (rev 18970) @@ -98,7 +98,7 @@ #ifdef __NR_msync /* msync(2). */ -CANCELABLE_SYSCALL (int, msync, (__ptr_t addr, size_t length, int flags), +CANCELABLE_SYSCALL (int, msync, (void *addr, size_t length, int flags), (addr, length, flags)) #endif From bugs at busybox.net Fri Jun 29 02:18:00 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 29 Jun 2007 02:18:00 -0700 Subject: [uClibc 0001403]: printf and anything using vfprintf() hangs system Message-ID: <82a9f138903f8f3c785d5b9cd516bf3a@bugs.busybox.net> A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1403 ====================================================================== Reported By: bjdooks Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1403 Category: Stdio Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-25-2007 17:22 PDT Last Modified: 06-29-2007 02:18 PDT ====================================================================== Summary: printf and anything using vfprintf() hangs system Description: Any function using vfprintf, such as printf and snprintf cause the system to stop. A test program shows that stdout is functional, as fwrite() to stdout will display messages on the console ====================================================================== ---------------------------------------------------------------------- bjdooks - 06-25-07 17:26 ---------------------------------------------------------------------- The bug is still present in the development snapshot ---------------------------------------------------------------------- bjdooks - 06-26-07 05:03 ---------------------------------------------------------------------- Building gcc 4.1.2 for OABI (patches will be sent in seperate report) does not work either. ---------------------------------------------------------------------- bjdooks - 06-29-07 02:18 ---------------------------------------------------------------------- Please see bug report 1406 for a better description of the problem, which is due to gcc producing ARMv5 instructions for ARMv4 processors. Issue History Date Modified Username Field Change ====================================================================== 06-25-07 17:22 bjdooks New Issue 06-25-07 17:22 bjdooks Status new => assigned 06-25-07 17:22 bjdooks Assigned To => uClibc 06-25-07 17:26 bjdooks Note Added: 0002514 06-26-07 05:03 bjdooks Note Added: 0002517 06-29-07 02:18 bjdooks Note Added: 0002531 ====================================================================== From bugs at busybox.net Fri Jun 29 10:01:22 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Fri, 29 Jun 2007 10:01:22 -0700 Subject: [uClibc 0001413]: fseek() does not propagate back errno Message-ID: <88936d19ba8741f8a7bc839003cdfaf7@bugs.busybox.net> The following issue has been SUBMITTED. ====================================================================== http://busybox.net/bugs/view.php?id=1413 ====================================================================== Reported By: kiltedknight Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1413 Category: Standards Compliance Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-29-2007 10:01 PDT Last Modified: 06-29-2007 10:01 PDT ====================================================================== Summary: fseek() does not propagate back errno Description: Compile and run the attached C program linked against uClibc. Both lseek() and fseek() return -1 as evidenced by the output coming from perror(), but fseek() has errno = 0, while lseek() has errno = ESPIPE. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 06-29-07 10:01 kiltedknight New Issue 06-29-07 10:01 kiltedknight Status new => assigned 06-29-07 10:01 kiltedknight Assigned To => uClibc 06-29-07 10:01 kiltedknight File Added: seek_test.c ====================================================================== From bugs at busybox.net Sat Jun 30 14:30:39 2007 From: bugs at busybox.net (bugs at busybox.net) Date: Sat, 30 Jun 2007 14:30:39 -0700 Subject: [uClibc 0001413]: fseek() does not propagate back errno Message-ID: A NOTE has been added to this issue. ====================================================================== http://busybox.net/bugs/view.php?id=1413 ====================================================================== Reported By: kiltedknight Assigned To: uClibc ====================================================================== Project: uClibc Issue ID: 1413 Category: Standards Compliance Reproducibility: always Severity: major Priority: normal Status: assigned ====================================================================== Date Submitted: 06-29-2007 10:01 PDT Last Modified: 06-30-2007 14:30 PDT ====================================================================== Summary: fseek() does not propagate back errno Description: Compile and run the attached C program linked against uClibc. Both lseek() and fseek() return -1 as evidenced by the output coming from perror(), but fseek() has errno = 0, while lseek() has errno = ESPIPE. ====================================================================== ---------------------------------------------------------------------- chombourger - 06-30-07 14:30 ---------------------------------------------------------------------- Using the latest (svn) uClibc, your program produces the following output in my test environment: lseek: Illegal seek fseek: Illegal seek Bug already fixed? Issue History Date Modified Username Field Change ====================================================================== 06-29-07 10:01 kiltedknight New Issue 06-29-07 10:01 kiltedknight Status new => assigned 06-29-07 10:01 kiltedknight Assigned To => uClibc 06-29-07 10:01 kiltedknight File Added: seek_test.c 06-29-07 10:01 kiltedknight Issue Monitored: kiltedknight 06-30-07 14:30 chombourger Note Added: 0002541 ======================================================================