RE: [ANNOUNCE] uClibc++-0.2.4 released
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Bernhard Reutner-Fischer Sent: den 26 maj 2012 00:23 To: Yann E. MORIN Cc: uclibc@uclibc.org Subject: Re: [ANNOUNCE] uClibc++-0.2.4 released On Fri, May 25, 2012 at 11:58:13PM +0200, Yann E. MORIN wrote: Bernhard, All, On Friday 25 May 2012 23:30:09 Bernhard Reutner-Fischer wrote: The uClibc team is proud to announce the release of uClibc-0.2.4. I take it you meant uClibc++-0.2.4 ;-) Indeed. My beloved wife interrupted me mid-sentence and when continuing i didn't notice, sorry for that.. Congrats! :-) I was thinking.. Now that you seem to have revived uClibc++, would it make sense to incorporate the source tree into uClibc? And have a 'C++' entry in the menuconfig, as we do have ' nope. uClibc++ is a c++ thing and a completely different (super)set of affairs. I believe this would be good, at least in one part: the build system. I just cloned the uClibc++ repository, and it just does not build: $ git clone Cloning into uClibc++... [...] $ cd uClibc++ $ git checkout v0.2.4 [...blabla detached head...] $ make menuconfig make[1]: Entering directory `/home/ymorin/tmp/uClibc++/extra/config' make[1]: *** ../../.config: Is a directory. Stop. make[1]: Leaving directory `/home/ymorin/tmp/uClibc++/extra/config' make: *** [extra/config/mconf] Error 2 huh? rm -rf /tmp/uc git clone git://git.uClibc.org/uClibc++ /tmp/uc cd /tmp/uc make menuconfig 2 /dev/null hit Exit, save; works make[1]: Entering directory `/tmp/uc/extra/config' cp zconf.tab.h_shipped zconf.tab.h gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c mconf.c -o mconf.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c checklist.c -o checklist.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c menubox.c -o menubox.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c textbox.c -o textbox.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c yesno.c -o yesno.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c inputbox.c -o inputbox.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c util.c -o util.o gcc -O2 -Wall -DCURSES_LOC=ncurses.h -I. -c msgbox.c -o msgbox.o cp zconf.tab.c_shipped zconf.tab.c cp lex.zconf.c_shipped lex.zconf.c gcc -O2 -Wall -I. -c zconf.tab.c -o zconf.tab.o gcc mconf.o checklist.o menubox.o textbox.o yesno.o inputbox.o util.o msgbox.o zconf.tab.o -o mconf -lncurses make[1]: Leaving directory `/tmp/uc/extra/config' # # using defaults found in extra/Configs/Config.default # *** End of uClibc configuration. *** Check the top-level Makefile for additional configuration options. Relatively to 'extra/config' , '../../.config' is in the top directory. But there's nothing in there: polluted env? Please paste your $ env somewhere. Double check against git grep getenv\( $ ls -A bin BugFinders ChangeLog DOCUMENTATION extra .git .gitignore include INSTALL Makefile README Rules.mak scripts src tests TODO $ find . -name .config [zilch] But if I touch the file first, it works: $ touch .config $ make menuconfig [OK, I get the menuconfig!] Using make-3.82 here on a Debian squeeze x86_64. i'm on current sid and it works fine, fwiw. Unrelated i suppose. I think the clue is make 3.82. Try with make 3.81 and it will most likely work as expected. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: uclibc 0.9.5
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rob Landley Sent: 21 October 2011 20:43 To: iggi Cc: uclibc@uclibc.org; Yann E. MORIN Subject: Re: uclibc 0.9.5 [cut] I really, really, really hate git. Show a file at a revision should not be esoteric knowlege. (What's git's equivalent of hg cat -r revision? It's not _quite_ git show 0ea968c3e603da9 -- Makefile because that just shows me the CHANGE to that one file. Oh well, Use this instead git show ref:file, i.e., git show 0ea968c3e603da9:Makefile [cut] Rob //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [git commit master 1/1] buildsys: prefer the form HEADERS_RM-$(config)
-Original Message- From: uclibc-cvs-boun...@uclibc.org [mailto:uclibc-cvs- boun...@uclibc.org] On Behalf Of Carmelo Amoroso Sent: 07 March 2011 18:31 To: uclibc-...@uclibc.org Subject: [git commit master 1/1] buildsys: prefer the form HEADERS_RM-$(config) commit: http://git.uclibc.org/uClibc/commit/?id=07044019e6260991729926645e7d221f38376f9d branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master Fix removal of sgtty.h using HEADERS_RM-$(config) syntax. Sort it alphabetically. Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- Makefile.in |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/Makefile.in b/Makefile.in index 995347b..dd88efc 100644 --- a/Makefile.in +++ b/Makefile.in @@ -222,9 +222,6 @@ HEADERS_RM- := \ rpc/des_crypt.h \ rpc/key_prot.h \ rpc/rpc_des.h -ifeq ($(UCLIBC_STRICT_HEADERS),y) -HEADERS_RM- += sgtty.h -endif HEADERS_RM-$(HAVE_SHARED)+= dlfcn.h bits/dlfcn.h HEADERS_RM-$(PTHREADS_DEBUG_SUPPORT) += thread_db.h HEADERS_RM-$(UCLIBC_HAS_BSD_ERR) += err.h @@ -275,6 +272,7 @@ HEADERS_RM-$(UCLIBC_LINUX_SPECIFIC) += sys/fsuid.h sys/inotify.h sys/pe sys/sysctl.h \ sys/sysinfo.h \ sys/vfs.h +HEADERS_RM-$(UCLIBC_STRICT_HEADERS) += sgtty.h This is _not_ the same as the removed ifeq-statement. The ifeq-statement above sets $(HEADERS_RM-) if $(UCLIBC_STRICT_HEADERS) is y, whereas the line above sets $(HEADERS_RM-) if $(UCLIBC_STRICT_HEADERS) is unset... This is untested, but should work: HEADERS_RM-$(if $(UCLIBC_STRICT_HEADERS),,y) += sgtty.h HEADERS_RM-$(UCLIBC_SUPPORT_AI_ADDRCONFIG) += ifaddrs.h HEADERS_RM-$(UCLIBC_SV4_DEPRECATED) += ustat.h sys/ustat.h bits/ustat.h HEADERS_RM-$(UCLIBC_SUSV3_LEGACY)+= sys/timeb.h regexp.h //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [patch] avoid c99 declaration
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Mike Frysinger Sent: den 1 augusti 2010 04:08 To: uclibc@uclibc.org Subject: Re: [patch] avoid c99 declaration On Saturday, July 31, 2010 16:22:35 Khem Raj wrote: On Tue, Jul 27, 2010 at 11:37 PM, Carmelo AMOROSO wrote: On 7/28/2010 7:51 AM, Mike Frysinger wrote: On Monday, June 21, 2010 06:39:12 Gianluigi Tiesi wrote: While compiling uClibc inside openwrt build system I have somehow the compiler without -std=c99 flash (since adding id causes me some troubles) why dont we fix uClibc to use c99 then ? if your toolchain is new enough to support TLS as NPTL requires, then it's new enough to support c99 features. we shouldnt go throwing frivolous patches at the NPTL code when we're merely importing it from glibc. realistically, we dont have the man power to maintain a fork which means we need to be sticking as lose to glibc as possible here. I definitely agree with Mike. Even if changes are dummy, merging effort with updated version of NPTL/glibc could be too huge. yes I agree. I proposed to make C99 a requirement for uclibc. i'm not necessarily set on all of uClibc, but certainly any part that utilizes TLS. i guess we could enable -std=gnu99 in the build and see who (if any) complains. if no one has anything else, i'll revert the changes in question and add -std=gnu99. -mike You already have this in Rules.mak: CPU_CFLAGS-y += $(call check_gcc,-std=gnu99,) so C99 should already be a requirement (at least for gcc)... //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [patch] avoid c99 declaration
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Khem Raj Sent: den 1 augusti 2010 10:11 To: Peter Kjellerstedt Cc: uclibc@uclibc.org Subject: Re: [patch] avoid c99 declaration On Sat, Jul 31, 2010 at 11:22 PM, Peter Kjellerstedt peter.kjellerst...@axis.com wrote: -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Mike Frysinger Sent: den 1 augusti 2010 04:08 To: uclibc@uclibc.org Subject: Re: [patch] avoid c99 declaration On Saturday, July 31, 2010 16:22:35 Khem Raj wrote: On Tue, Jul 27, 2010 at 11:37 PM, Carmelo AMOROSO wrote: On 7/28/2010 7:51 AM, Mike Frysinger wrote: On Monday, June 21, 2010 06:39:12 Gianluigi Tiesi wrote: While compiling uClibc inside openwrt build system I have somehow the compiler without -std=c99 flash (since adding id causes me some troubles) why dont we fix uClibc to use c99 then ? if your toolchain is new enough to support TLS as NPTL requires, then it's new enough to support c99 features. we shouldnt go throwing frivolous patches at the NPTL code when we're merely importing it from glibc. realistically, we dont have the man power to maintain a fork which means we need to be sticking as lose to glibc as possible here. I definitely agree with Mike. Even if changes are dummy, merging effort with updated version of NPTL/glibc could be too huge. yes I agree. I proposed to make C99 a requirement for uclibc. i'm not necessarily set on all of uClibc, but certainly any part that utilizes TLS. i guess we could enable -std=gnu99 in the build and see who (if any) complains. if no one has anything else, i'll revert the changes in question and add -std=gnu99. -mike You already have this in Rules.mak: CPU_CFLAGS-y += $(call check_gcc,-std=gnu99,) so C99 should already be a requirement (at least for gcc)... No. its only turned on if gcc supports it. what I proposed was to have it turned on always. And if the compiler does not support it, how do you propose to turn it on? I thought gcc is not the only compiler used to compile uClibc, but I may be wrong as I never used anything other than gcc myself. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [patch] avoid c99 declaration
-Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: den 1 augusti 2010 10:48 To: Peter Kjellerstedt Cc: uclibc@uclibc.org Subject: Re: [patch] avoid c99 declaration On Sun, Aug 1, 2010 at 1:35 AM, Peter Kjellerstedt peter.kjellerst...@axis.com wrote: -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Khem Raj Sent: den 1 augusti 2010 10:11 To: Peter Kjellerstedt Cc: uclibc@uclibc.org Subject: Re: [patch] avoid c99 declaration On Sat, Jul 31, 2010 at 11:22 PM, Peter Kjellerstedt peter.kjellerst...@axis.com wrote: -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Mike Frysinger Sent: den 1 augusti 2010 04:08 To: uclibc@uclibc.org Subject: Re: [patch] avoid c99 declaration On Saturday, July 31, 2010 16:22:35 Khem Raj wrote: On Tue, Jul 27, 2010 at 11:37 PM, Carmelo AMOROSO wrote: On 7/28/2010 7:51 AM, Mike Frysinger wrote: On Monday, June 21, 2010 06:39:12 Gianluigi Tiesi wrote: While compiling uClibc inside openwrt build system I have somehow the compiler without -std=c99 flash (since adding id causes me some troubles) why dont we fix uClibc to use c99 then ? if your toolchain is new enough to support TLS as NPTL requires, then it's new enough to support c99 features. we shouldnt go throwing frivolous patches at the NPTL code when we're merely importing it from glibc. realistically, we dont have the man power to maintain a fork which means we need to be sticking as lose to glibc as possible here. I definitely agree with Mike. Even if changes are dummy, merging effort with updated version of NPTL/glibc could be too huge. yes I agree. I proposed to make C99 a requirement for uclibc. i'm not necessarily set on all of uClibc, but certainly any part that utilizes TLS. i guess we could enable -std=gnu99 in the build and see who (if any) complains. if no one has anything else, i'll revert the changes in question and add -std=gnu99. -mike You already have this in Rules.mak: CPU_CFLAGS-y += $(call check_gcc,-std=gnu99,) so C99 should already be a requirement (at least for gcc)... No. its only turned on if gcc supports it. what I proposed was to have it turned on always. And if the compiler does not support it, how do you propose to turn it on? huh? if C99 is a requirement then you better use a compiler that supports it. What I meant was that -std=gnu99 is a gcc specific option. However, as Bernhard mentioned, gcc is needed in practice to compile uClibc, so then that is not a problem any more. thats what is meant with adding a c99 requirement to uclibc. I thought gcc is not the only compiler used to compile uClibc, but I may be wrong as I never used anything other than gcc myself. c99 is not a gcc standard its a ISO C language standard gcc is one of the compilers that support it. Of course. However, _how_ to require C99 is compiler specific. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: powerpc NPTL port
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rob Landley Sent: den 9 maj 2010 08:16 To: Khem Raj Cc: uclibc@uclibc.org Subject: Re: powerpc NPTL port [cut] (I hate git. I really hate git. The UI is horrendous. Even with -v it won't tell me the names of hte files that were involved in the commit. There's no obvious way to get it to follow renames. Yes, I added -M and it still didn't. Right, it wanted --follow. And it's _STILL not showing me the names of the files...) git log --stat should show you the files that are involved in each commit. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: problems with gnu make and stdout with uclibc nptl
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Natanael Copa Sent: den 9 april 2010 10:08 To: Bernhard Reutner-Fischer Cc: uclibc@uclibc.org Subject: Re: problems with gnu make and stdout with uclibc nptl On Thu, Apr 8, 2010 at 8:40 AM, Natanael Copa natanael.c...@gmail.com wrote: On Wed, Apr 7, 2010 at 11:20 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: Does it still happen if you build master with LT_OLD and O0 (i.e. DODEBUG set)? Enabling runtime assertions did give an interesting result: make: libc/stdio/_stdio.c: 326: _stdio_validate_FILE: Assertion `stream-__modeflags == (0x0020U|0x0010U)' failed. The problem comes from 885f507317b6c8576ba2e298c2249d27ea6f8404 which breaks ABI compat and the gnu make i used was built against previous uclibc headers things went wrong. I think it would be nice if the MAJOR_VERSION changed every time the ABI changed as it gives people who does not do firmware style upgrades (i.e package managers) a chance to do clean upgrades. I think this alone is more than good enough reason to let next release be 1.x in stead of 0.9.32. (It still leaves 0.9.31 release as non-upgradeable) thanks! -- Natanael Copa Unless it has changed in the last years, there are no expressed guarantees regarding API and ABI stability for the 0.x.y releases of uClibc. AFAIK the stable API/ABI is intended for the 1.0.0 release. And with the upcoming integration of the NPTL support, I do not see this as the right time to go to 1.0.0 and lock down the API/ABI... //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [git commit master] ftw.h installation: fix inverted logic
-Original Message- From: uclibc-cvs-boun...@uclibc.org [mailto:uclibc-cvs- boun...@uclibc.org] On Behalf Of Bernhard Reutner-Fischer Sent: den 23 januari 2010 22:37 To: uclibc-...@uclibc.org Subject: [git commit master] ftw.h installation: fix inverted logic commit: http://git.uclibc.org/uClibc/commit/?id=d75f980f379dfbbe70ae8fb0956693a95af2fca2 branch: http://git.uclibc.org/uClibc/commit/?id=refs/heads/master Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com --- Makefile.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.in b/Makefile.in index 39dd18c..879b730 100644 --- a/Makefile.in +++ b/Makefile.in @@ -262,7 +262,7 @@ HEADERS_RM-$(UCLIBC_HAS_BSD_ERR) += err.h HEADERS_RM-$(UCLIBC_HAS_CRYPT) += crypt.h HEADERS_RM-$(UCLIBC_HAS_EPOLL) += sys/epoll.h HEADERS_RM-$(UCLIBC_HAS_FENV)+= fenv.h bits/fenv.h bits/fenvinline.h -HEADERS_RM-$(findstring y,$(UCLIBC_HAS_FTW)$(UCLIBC_HAS_NFTW)) += ftw.h +HEADERS_RM-$(if $(findstring y,$(UCLIBC_HAS_FTW)$(UCLIBC_HAS_NFTW)),,y) += ftw.h I may of course be reading the test above incorrectly, but as far as I can deduct, the above code will prevent ftw.h from being installed if $(UCLIBC_HAS_FTW) and/or $(UCLIBC_HAS_NFTW) is y. This seems wrong. I would have assumed the following to be what you want: HEADERS_RM-$(UCLIBC_HAS_FTW)$(UCLIBC_HAS_NFTW) += ftw.h Remember that it is $(HEADERS_RM-) that is later used to actually remove the unwanted include files. HEADERS_RM-$(UCLIBC_HAS_GETTEXT_AWARENESS) += libintl.h HEADERS_RM-$(UCLIBC_HAS_GLIBC_CUSTOM_PRINTF) += printf.h HEADERS_RM-$(UCLIBC_HAS_GLOB)+= glob.h //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH] realpath: SUSv4 compliant
-Original Message-
From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf
Of Bernhard Reutner-Fischer
Sent: den 12 november 2009 21:08
To: uclibc@uclibc.org
Subject: [PATCH] realpath: SUSv4 compliant
Signed-off-by: Mike Frysinger vap...@gentoo.org
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
include/stdlib.h |2 --
libc/stdlib/realpath.c | 20
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/include/stdlib.h b/include/stdlib.h
index e462c1c..3e9ceab 100644
--- a/include/stdlib.h
+++ b/include/stdlib.h
@@ -659,7 +659,6 @@ extern char *canonicalize_file_name (__const char *__name)
__THROW __nonnull ((1)) __wur;
#endif
-#if defined __USE_BSD || defined __USE_XOPEN_EXTENDED
/* Return the canonical absolute name of file NAME. If RESOLVED is
null, the result is malloc'd; otherwise, if the canonical name is
PATH_MAX chars or more, returns null with `errno' set to
@@ -668,7 +667,6 @@ extern char *canonicalize_file_name (__const char
*__name)
/* we choose to handle __resolved==NULL as crash :) */
extern char *realpath (__const char *__restrict __name,
char *__restrict __resolved) __THROW __wur
__nonnull((2));
-#endif
/* Shorthand for type of comparison functions. */
diff --git a/libc/stdlib/realpath.c b/libc/stdlib/realpath.c
index 1a00c31..3c3a607 100644
--- a/libc/stdlib/realpath.c
+++ b/libc/stdlib/realpath.c
@@ -36,19 +36,12 @@
#define MAX_READLINKS 32
-#ifdef __STDC__
char *realpath(const char *path, char got_path[])
-#else
-char *realpath(path, got_path)
-const char *path;
-char got_path[];
-#endif
{
char copy_path[PATH_MAX];
/* use user supplied buffer directly - reduces stack usage */
/* char got_path[PATH_MAX]; */
- char *max_path;
- char *new_path;
+ char *max_path, *new_path, *allocated_path;
Why aggregate multiple variables on one line?
I have always found that to be a bad idea(tm).
size_t path_len;
int readlinks = 0;
#ifdef S_IFLNK
@@ -72,12 +65,13 @@ char got_path[];
/* Copy so that path is at the end of copy_path[] */
strcpy(copy_path + (PATH_MAX-1) - path_len, path);
path = copy_path + (PATH_MAX-1) - path_len;
+ allocated_path = got_path ? NULL : malloc(PATH_MAX);
I may be blind, but as far as I can tell you never use
allocated_path for anything (except freeing it)...
max_path = got_path + PATH_MAX - 2; /* points to last non-NUL char */
new_path = got_path;
if (*path != '/') {
/* If it's a relative pathname use getcwd for starters. */
if (!getcwd(new_path, PATH_MAX - 1))
- return NULL;
+ goto err;
new_path += strlen(new_path);
if (new_path[-1] != '/')
*new_path++ = '/';
@@ -114,6 +108,8 @@ char got_path[];
while (*path != '\0' *path != '/') {
if (new_path max_path) {
__set_errno(ENAMETOOLONG);
+ err:
+ free(allocated_path);
return NULL;
}
*new_path++ = *path++;
@@ -122,7 +118,7 @@ char got_path[];
/* Protect against infinite loops. */
if (readlinks++ MAX_READLINKS) {
__set_errno(ELOOP);
- return NULL;
+ goto err;
}
path_len = strlen(path);
/* See if last (so far) pathname component is a symlink. */
@@ -133,13 +129,13 @@ char got_path[];
if (link_len 0) {
/* EINVAL means the file exists but isn't a
symlink. */
if (errno != EINVAL) {
- return NULL;
+ goto err;
}
} else {
/* Safe sex check. */
if (path_len + link_len = PATH_MAX - 2) {
__set_errno(ENAMETOOLONG);
- return NULL;
+ goto err;
}
/* Note: readlink doesn't add the null byte. */
/* copy_path[link_len] = '\0'; - we don't need
it too */
--
1.6.3.3
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: Quick and dirty malloc() support for realpath.
-Original Message-
From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On
Behalf Of Mike Frysinger
Sent: den 28 oktober 2009 09:02
To: uclibc@uclibc.org
Subject: Re: Quick and dirty malloc() support for realpath.
[ cut ]
@@ -114,6 +114,8 @@ char got_path[];
while (*path != '\0' *path != '/') {
if (new_path max_path) {
__set_errno(ENAMETOOLONG);
+ err:
+ free(allocated_path);
return NULL;
Fore readability, wouldn't it be better to put the three lines
above at the end of the function, and just put another goto err
here? Or is there some other reason to have the error exit path
in the middle of the function?
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: Quick and dirty malloc() support for realpath.
-Original Message-
From: Mike Frysinger [mailto:vap...@gentoo.org]
Sent: den 28 oktober 2009 10:13
To: Peter Kjellerstedt
Cc: uclibc@uclibc.org
Subject: Re: Quick and dirty malloc() support for realpath.
On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
From: Mike Frysinger
[ cut ]
@@ -114,6 +114,8 @@ char got_path[];
while (*path != '\0' *path != '/') {
if (new_path max_path) {
__set_errno(ENAMETOOLONG);
+ err:
+ free(allocated_path);
return NULL;
Fore readability, wouldn't it be better to put the three lines
above at the end of the function, and just put another goto err
here? Or is there some other reason to have the error exit path
in the middle of the function?
i stated the reason for doing this in the part you [ cut ]. it was
all of two sentences :P.
-mike
Well, it wasn't in the code which explains why I didn't see it. ;)
[ Re-add the cut part: ]
our friend goto solves the leak. stick it in the middle of the file to
maximize short forward/backward jumps and we only get a small increase:
So, in effect it is an architecture specific optimization.
With that kind of optimization, isn't it a sign that the
function is too long and should be split?
In any case, there should be a comment explaining why the exit path
is in the middle of the function, or someone is bound to rearrange
the code for readability at a later stage.
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: license info for ucLibc
What do you mean by uClibc contains a link to LGPLv3? Where? However, to answer your question, uClibc as a whole is LGPLv2.1 only. Specific files may be under less restrictive licenses though, e.g., LGPLv2.1 or later, BSD, etc. //Peter From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Live Coder Sent: den 14 maj 2009 22:02 To: uclibc@uclibc.org Subject: license info for ucLibc uClibc contains a link to LGPLv3 whereas the downloaded tarball contains LGPLv2 license http://git.uclibc.org/uClibc/tree/COPYING.LIB. Can someone confirm that indeed it is released with LGPLv2? Thanks. Hotmail(r) has ever-growing storage! Don't worry about storage limits. Check it out.http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009 ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: no mail after git-push ?
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Mike Frysinger Sent: den 6 maj 2009 11:43 To: uclibc@uclibc.org Subject: Re: no mail after git-push ? On Wednesday 06 May 2009 05:24:50 Will Newton wrote: On Tue, May 5, 2009 at 6:27 PM, Carmelo AMOROSO wrote: is not possible to receive git=push notificaation by emails as we had for svn commit ? The post-recieve-email hook in the git contrib directory should do what you want. Ian configured the repos to use that already, but for some reason it isnt working. imo, the format sucks hard anyways, so i implemented my own hook based on format-patch. should be working now ... i'll run it manually to send out old commits though. -mike A step in the right direction, but the mails (judging by the ones I received for busybox) seem to be lacking some vital information, e.g., the sha1 of the commit, what branch it was made on, and preferably a link to the web where the commit can be seen. Also I would very much prefer to have the subject line of the commit message remain in the body since at least the mail reader I use has quite some distance between the mail subject and mail body which means I need to move my eyes up and down to first read the subject, and then read the rest of the body, rather than just read the bodies which I am used to... Please find attached the post-receive script that GStreamer uses. Even if you do not want to use it literally, I hope it may be of some inspiration. It has the mail list and web URL hard coded, but that should be easy enough to change to use git config instead. //Peter post-receive Description: post-receive ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: no mail after git-push ?
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: den 6 maj 2009 12:40 To: Peter Kjellerstedt Cc: uclibc@uclibc.org Subject: Re: no mail after git-push ? On Wednesday 06 May 2009 06:07:13 Peter Kjellerstedt wrote: From Mike Frysinger: On Wednesday 06 May 2009 05:24:50 Will Newton wrote: On Tue, May 5, 2009 at 6:27 PM, Carmelo AMOROSO wrote: is not possible to receive git=push notificaation by emails as we had for svn commit ? The post-recieve-email hook in the git contrib directory should do what you want. Ian configured the repos to use that already, but for some reason it isnt working. imo, the format sucks hard anyways, so i implemented my own hook based on format-patch. should be working now ... i'll run it manually to send out old commits though. A step in the right direction, but the mails (judging by the ones I received for busybox) seem to be lacking some vital information, e.g., the sha1 of the commit, what branch it was made on read the actual e-mail. there are X-* tags in there with all relevant information. Ah, then it's there at least; just a bit harder to find... preferably a link to the web where the commit can be seen the old commit log didnt have it so i didnt add it to the new one. but i dont have a problem adding it. Also I would very much prefer to have the subject line of the commit message remain in the body since at least the mail reader I use has quite some distance between the mail subject and mail body which means I need to move my eyes up and down to first read the subject, and then read the rest of the body, rather than just read the bodies which I am used to... get a better reader ? unless there's other people who would prefer this change, i'm inclined to not do it ... Maybe it is just me, but when reading commit mails I am used to only reading the body for the actual commit message. I only glance briefly at the list of subjects before starting to read the actual messages. Please find attached the post-receive script that GStreamer uses. Even if you do not want to use it literally, I hope it may be of some inspiration. It has the mail list and web URL hard coded, but that should be easy enough to change to use git config instead. perl is not my thing, so it wont be too much assistance in terms of copy paste. do you have a URL for an example commit message generated by this ? Here is the mail archive for GStreamer's commit mails: http://sourceforge.net/mailarchive/forum.php?forum_name=gstreamer-cvsmax_rows=25style=nestedviewmonth=200905 For short diffs (10kB by default) it includes the diff in the mail, and for longer diffs it includes a link instead -mike //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: HEADS UP: svn-git transition
-Original Message- From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On Behalf Of Mike Frysinger Sent: den 5 maj 2009 09:57 To: uclibc@uclibc.org Cc: busy...@busybox.net; Bernhard Reutner-Fischer; buildr...@uclibc.org Subject: Re: HEADS UP: svn-git transition ive updated the uclibc.org website to include git info: http://uclibc.org/developing.html any feedback would be great -mike May I suggest the following commands instead of manually editing .gitconfig: git config --global user.name Your Full Name git config --global user.email your.real.em...@address.com And I doubt you want the email address for the uClibc list to be in the global configuration file, so for sendemail.to I would suggest: git config sendemail.to uclibc@uclibc.org which needs to be executed while in the cloned uClibc directory. I also think there should be something about the format of commit messages (i.e., one subject line, one empty line and then the full description). //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: HEADS UP: svn-git transition
-Original Message- From: Thierry Reding [mailto:thierry.red...@avionic-design.de] Sent: den 30 april 2009 13:37 To: Bernd Schmidt Cc: Peter Kjellerstedt; busy...@busybox.net; uclibc@uclibc.org; buildr...@uclibc.org Subject: Re: HEADS UP: svn-git transition * Bernd Schmidt wrote: Peter Kjellerstedt wrote: -Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Mike Frysinger Sent: den 29 april 2009 18:59 To: uclibc@uclibc.org Cc: busy...@busybox.net; buildr...@uclibc.org Subject: Re: HEADS UP: svn-git transition On Wednesday 29 April 2009 12:52:29 Bernd Schmidt wrote: Bernhard Reutner-Fischer wrote: git push -v --thin git+ssh://$usern...@uclibc.org/srv/git/uClibc.git Huh. Does git really work if multiple people push to the same repository? That's news to me. All the online examples seem to suggest using git push as a means to provide a git-pullable repository for others, but not for writing to a central repository. afaik it should work fine. if you try to push and someone else already has, you'll get the typical rejecting non-fast forward update. That seems to be correct, I've reproduced this locally with some test repositories. It works fine, but requires some discipline. E.g., the GStreamer project uses git this way. One of the important things to remember when using a central git repository in this way is to always rebase the local repository before pushing. Otherwise you will end up with a lot of unnecessary merges. So what are the steps once you get the error message mentioned above? I git pulled after that and ended up with a merge. You use git fetch to update the local repository with the latest changes from the remote repository, then use git rebase origin/master to rebase all local commits onto the master branch of the origin repository. origin/master can of course be substituted with any other branch as well. After that you can git push your new branch to the remote repository. Bernd Thierry Another way is to use git pull --rebase. It basically does git fetch + git rebase, rather than git fetch + git merge that the normal git pull does. A good way to make sure what you are pushing will not result in a merge is to use gitk (or giggle) before the push. If the graph showing the commits is a straight line all is good, otherwise you need to rebase. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: HEADS UP: svn-git transition
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Mike Frysinger Sent: den 29 april 2009 18:59 To: uclibc@uclibc.org Cc: busy...@busybox.net; buildr...@uclibc.org Subject: Re: HEADS UP: svn-git transition On Wednesday 29 April 2009 12:52:29 Bernd Schmidt wrote: Bernhard Reutner-Fischer wrote: git push -v --thin git+ssh://$usern...@uclibc.org/srv/git/uClibc.git Huh. Does git really work if multiple people push to the same repository? That's news to me. All the online examples seem to suggest using git push as a means to provide a git-pullable repository for others, but not for writing to a central repository. afaik it should work fine. if you try to push and someone else already has, you'll get the typical rejecting non-fast forward update. -mike It works fine, but requires some discipline. E.g., the GStreamer project uses git this way. One of the important things to remember when using a central git repository in this way is to always rebase the local repository before pushing. Otherwise you will end up with a lot of unnecessary merges. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: SVN head breaks a lot of apps, 0.9.30 works
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rob Landley Sent: den 26 februari 2009 08:05 To: uclibc@uclibc.org Cc: rhabarber1848 Subject: Re: SVN head breaks a lot of apps, 0.9.30 works On Wednesday 25 February 2009 12:14:22 Bernhard Reutner-Fischer wrote: On Tue, Feb 24, 2009 at 06:24:37PM +0100, Denys Vlasenko wrote: On Monday 23 February 2009 08:07:42 pm rhabarber1848 wrote: Denys Vlasenko wrote: Meanwhile, try unsetting LINUXTHREADS_OLD=y in your .config, does it work after that? -- Hi, no. This activates LINUXTHREADS_NEW which I, unfortunately, was never able to compile: CC libpthread/linuxthreads/sysdeps/powerpc/pspinlock.oS libpthread/linuxthreads/sysdeps/pthread/errno-loc.c:23:27: sysdep-cancel.h: No such file or directory Apparently it stays that way since rev 13745 (three years old). That rev did initial import of latest linuxthreads which is likely never worked. I would say keeping this cruft around does more harm than good. LT_NEW does not support all arches (same for LT_OLD). If somebody wants to help to cut down on the number of thread impls then go add support for your arch to NPTL which should replace both LT_NEW and LT_OLD mid-term. Is there a list of which arches each supports? I currently use LINUXTHREADS_OLD for every target in FWL. I have working test environments (built from source and bootable to a shell prompt under qemu) for arm, mips, powerpc, sh4, x86, and x86_64. Sparc builds but only works statically linked (need to debug what's up with the dynamic loader), and m68k I need to find a decent emulator for (qemu only supports coldfire). (I have random bits of cris and bfin and alpha such, but qemu hasn't got quite enough support for them for me to finish either yet. No bfin at all, cris and alpha were missing usable board emulations last I checked.) uClibc claims to support: alpha, arm, avr32, bfin, cris, e1, frv, h8300, hppa, i386, i960, ia64, m68k, microblaze, mips, nios, nios2, powerpc, superh, sh64, sparc, v850, vax, x86_64, and xtensa. I know arm, i386,mips, powerpc, superh, and x86_64 all work with linuxthreads_old. I know m68k and sparc at least compile with it. I believe Alpha, hppa, and i960, and vax are all archaic and discontinued. (I'm still vaguely interested in supporting them, but it's hard to work up a lot of enthusiasm for something with no new deployments.) No human being cares about ia64 unless paid to do so by a large pointy-haired corporation operating on sheer inertia. Whatever e1 is, it's acknowledged broken in the config. That leaves avr32, bfin, cris, frv, h8300, microblaze, nios, nios2, sh64, v850, and xtensa. Which of these don't work with LINUXTHREADS_OLD, and are there emulators for any of them that I might be able to test boot stuff with? Rob It is linuxthreads_old for CRIS. Never got the new linuxthread to compile for it (didn't give it much of an effort though). //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: Adding a new config option, mind if I check this in?
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of Rob Landley Sent: den 24 februari 2009 06:00 To: uclibc@uclibc.org Subject: Adding a new config option, mind if I check this in? I'm getting the svn version of uClibc to compile under FWL again so I can do nightly builds of cross compiler toolchains and root filesystems for downloads/binaries. (I'll move the current stuff into a 0.9.30 directory and add a snapshot directory, or something, before I set up the cron job.) Anyway, I'm trying to get the number of patches I carry in FWL down to a dull roar. This is a patch I've had in FWL forever, cleaned up and ready to submit. Sound reasonable? (There's a help entry at the end explaining why.) Rob Given that we have a very similar patch in our local version of uClibc, I would like to see this patch applied as well. //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Bug tracker
Have I missed some announcement that the bug tracker used for uClibc has changed? I just noticed that I had not received any mails about bugs since Nov 17 (which used to be sent to uclibc-...@uclibc.org), so I went to http://bugs.uclibc.org/ and noticed that there now is a Bugzilla tracker. I assume this has to do with the resent changes of hosting, but some kind of announcement may have been a good idea. Also, is the old bug tracker available somewhere, or are all the old bug reports lost? //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: svn commit: trunk/uClibc: include
This has (almost) been tried before. Then it was -fsigned-char,
but I think this thread from 2007 still bears meaning (especially
Mike's mail):
http://lists.busybox.net/pipermail/uclibc/2007-April/038622.html
//Peter
-Original Message-
From: uclibc-cvs-boun...@uclibc.org [mailto:uclibc-cvs-
boun...@uclibc.org] On Behalf Of v...@uclibc.org
Sent: den 26 december 2008 03:50
To: uclibc-...@uclibc.org
Subject: svn commit: trunk/uClibc: include
Author: vda
Date: 2008-12-26 02:50:13 + (Fri, 26 Dec 2008)
New Revision: 24546
Log:
include/libc-string_i386.h: fix a bug where memset('\xff') misbehaves
Rules.mak: add -funsigned-char, to forestall future PITA
Modified:
trunk/uClibc/Rules.mak
trunk/uClibc/include/libc-string_i386.h
Changeset:
Modified: trunk/uClibc/Rules.mak
===
--- trunk/uClibc/Rules.mak2008-12-25 19:26:23 UTC (rev 24545)
+++ trunk/uClibc/Rules.mak2008-12-26 02:50:13 UTC (rev 24546)
@@ -467,9 +467,11 @@
NOSTDLIB_CFLAGS:=$(call check_gcc,-nostdlib,)
# Some nice CFLAGS to work with
+# Why -funsigned-char: I hunted a bug related to incorrect
+# sign extension of 'char' type for 10 hours straight. Not fun.
CFLAGS := -include $(top_builddir)include/libc-symbols.h \
$(XWARNINGS) $(CPU_CFLAGS) $(SSP_CFLAGS) \
- -fno-builtin -nostdinc -I$(top_builddir)include -I. \
+ -funsigned-char -fno-builtin -nostdinc -I$(top_builddir)include -
I. \
-I$(top_srcdir)libc/sysdeps/linux/$(TARGET_ARCH)
# Make sure that we can be built with non-C99 compilers, too.
Modified: trunk/uClibc/include/libc-string_i386.h
===
--- trunk/uClibc/include/libc-string_i386.h 2008-12-25 19:26:23 UTC
(rev 24545)
+++ trunk/uClibc/include/libc-string_i386.h 2008-12-26 02:50:13 UTC
(rev 24546)
@@ -26,7 +26,9 @@
return s;
}
- eax *= 0x01010101; /* done at compile time */
+ /* You wonder why 0xff is needed? Try memset(p, '\xff', size).
+ * If char is signed, '\xff' == -1! */
+ eax = (eax 0xff) * 0x01010101; /* done at compile time */
if (count == 2) {
*(short *)(s + 0) = eax;
___
uClibc-cvs mailing list
uclibc-...@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc-cvs
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
RE: [PATCH] ldso - adding ARCH_NEEDS_BOOTSTRAP_RELOCS define
-Original Message- From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On Behalf Of olsaj...@gmail.com Sent: den 6 januari 2009 23:33 To: carmel...@gmail.com; joakim.tjernl...@transmode.se; uclibc@uclibc.org Subject: [PATCH] ldso - adding ARCH_NEEDS_BOOTSTRAP_RELOCS define Hi, I changed the define, and add check in the #else case for non relative relocs which calls _dl_exit(14) (it was there before for some goof stuff, but I'm not sure about the rules for the exit return value...). I added ARCH_NEEDS_BOOTSTRAP_RELOCS to all archs except for arm, x86, powerpc and x86_64. I also add change for the include/tls.h, I'm not sure why it is not defined, however this kills many warnings for me. I'm ready to remove it :). cheers, jirka --- Index: include/tls.h === --- include/tls.h (revision 24692) +++ include/tls.h (working copy) @@ -5,7 +5,7 @@ #include_next tls.h -#if USE_TLS HAVE___THREAD \ +#if defined USE_TLS HAVE___THREAD \ To maintain functionality, that should be: #if defined USE_TLS USE_TLS HAVE___THREAD \ (!defined NOT_IN_libc || defined IS_IN_libpthread || defined IS_IN_librt) # define USE___THREAD 1 //Peter ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
RE: svn commit: trunk/uClibc: include libc/sysdeps/linux/common
-Original Message- From: [EMAIL PROTECTED] [mailto:uclibc-cvs- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: den 18 november 2008 14:04 To: [EMAIL PROTECTED] Subject: svn commit: trunk/uClibc: include libc/sysdeps/linux/common Author: aldot Date: 2008-11-18 05:03:34 -0800 (Tue, 18 Nov 2008) New Revision: 24092 Log: - add __hot and __cold annotations Will spare us quite some likely()/unlikely() occurances. See http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html for details Modified: trunk/uClibc/include/libc-symbols.h trunk/uClibc/libc/sysdeps/linux/common/ssp.c Changeset: Modified: trunk/uClibc/include/libc-symbols.h === --- trunk/uClibc/include/libc-symbols.h 2008-11-18 12:56:05 UTC (rev 24091) +++ trunk/uClibc/include/libc-symbols.h 2008-11-18 13:03:34 UTC (rev 24092) @@ -63,6 +63,14 @@ #ifndef unlikely # define unlikely(x) __builtin_expect((!!(x)),0) #endif +#if defined __GNUC__ !(__GNUC__ == 4 __GNUC_MINOR__ 3) +# ifndef __cold +# define __cold __attribute__ ((__cold__)) +# endif +# ifndef __hot +# define __hot __attribute__ ((__hot__)) +# endif +#endif #ifndef __LINUX_COMPILER_H # define __LINUX_COMPILER_H #endif The above will not work for any compiler older than 4.3. For compilers with version 4.0 and 4.1 it will not work because __cold and __hot are never defined, and for compilers older than 4.0 (yes, some of us are limited to use such old compilers) it will not work because __cold and __hot _are_ defined (but the attributes do not exist). Please consider using the following code instead: #if defined __GNUC__ (__GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ = 3)) # ifndef __cold # define __cold __attribute__ ((__cold__)) # endif # ifndef __hot # define __hot __attribute__ ((__hot__)) # endif #else # ifndef __cold # define __cold # endif # ifndef __hot # define __hot # endif #endif //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Strange location of kernel-features.h
Can anyone explain to me why kernel-features.h is placed in
libpthread/linuxthreads/sysdeps/pthread? As far as I can tell
there is nothing pthread related in that file.
This placement will prevent the changes made below by Carmelo in
libc/sysdeps/linux/common/getdents.c from taking effect for no
apparent reason at all if one uses libpthread/linuxthreads.old.
Moreover, if __ASSUME_GETDENTS32_D_TYPE actually happens to be
defined while compiling getdents.c when using
libpthread/linuxthreads I would say that is more of an accident
than anything else since there are no indications in the list of
included files that one is expecting kernel-features.h to be
included...
//Peter
-Original Message-
From: [EMAIL PROTECTED] [mailto:uclibc-cvs-
[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: den 9 september 2008 14:02
To: [EMAIL PROTECTED]
Subject: svn commit: trunk/uClibc: libc/sysdeps/linux/common libpthread/lin
etc...
Author: carmelo
Date: 2008-09-09 05:01:37 -0700 (Tue, 09 Sep 2008)
New Revision: 23363
Log:
Use getdents syscall if kernel provide supports for this
instead of relying upon getdents64.
Signed-off-by: Filippo Arcidiacono [EMAIL PROTECTED]
Signed-off-by: Carmelo Amoroso [EMAIL PROTECTED]
Modified:
trunk/uClibc/libc/sysdeps/linux/common/getdents.c
trunk/uClibc/libpthread/linuxthreads/sysdeps/pthread/kernel-features.h
Changeset:
Modified: trunk/uClibc/libc/sysdeps/linux/common/getdents.c
===
--- trunk/uClibc/libc/sysdeps/linux/common/getdents.c 2008-09-09
08:50:18 UTC (rev 23362)
+++ trunk/uClibc/libc/sysdeps/linux/common/getdents.c 2008-09-09
12:01:37 UTC (rev 23363)
@@ -18,8 +18,7 @@
#include bits/kernel_types.h
/* With newer versions of linux, the getdents syscall returns d_type
- * information after the name field. Someday, we should add support for
- * that instead of always calling getdents64 ...
+ * information after the name field.
*
* See __ASSUME_GETDENTS32_D_TYPE in glibc's kernel-features.h for specific
* version / arch details.
@@ -39,14 +38,42 @@
ssize_t __getdents (int fd, char *buf, size_t nbytes) attribute_hidden;
-#if ! defined __UCLIBC_HAS_LFS__ || ! defined __NR_getdents64
+#define __NR___syscall_getdents __NR_getdents
+static inline _syscall3(int, __syscall_getdents, int, fd, unsigned char *,
kdirp, size_t, count);
+#ifdef __ASSUME_GETDENTS32_D_TYPE
+ssize_t __getdents (int fd, char *buf, size_t nbytes)
+{
+ ssize_t retval;
+
+ retval = __syscall_getdents(fd, (unsigned char *)buf, nbytes);
+
+ /* The kernel added the d_type value after the name. Change
+ this now. */
+ if (retval != -1) {
+ union {
+ struct kernel_dirent k;
+ struct dirent u;
+ } *kbuf = (void *) buf;
+
+ while ((char *) kbuf buf + retval) {
+ char d_type = *((char *) kbuf + kbuf-k.d_reclen - 1);
+ memmove (kbuf-u.d_name, kbuf-k.d_name,
+ strlen (kbuf-k.d_name) + 1);
+ kbuf-u.d_type = d_type;
+
+ kbuf = (void *) ((char *) kbuf + kbuf-k.d_reclen);
+ }
+ }
+
+ return retval;
+}
+
+#elif ! defined __UCLIBC_HAS_LFS__ || ! defined __NR_getdents64
+
/* Experimentally off - libc_hidden_proto(memcpy) */
libc_hidden_proto(lseek)
-#define __NR___syscall_getdents __NR_getdents
-static __inline__ _syscall3(int, __syscall_getdents, int, fd, unsigned char
*, kdirp, size_t, count);
-
ssize_t __getdents (int fd, char *buf, size_t nbytes)
{
struct dirent *dp;
Modified: trunk/uClibc/libpthread/linuxthreads/sysdeps/pthread/kernel-
features.h
===
--- trunk/uClibc/libpthread/linuxthreads/sysdeps/pthread/kernel-features.h
2008-09-09 08:50:18 UTC (rev 23362)
+++ trunk/uClibc/libpthread/linuxthreads/sysdeps/pthread/kernel-features.h
2008-09-09 12:01:37 UTC (rev 23363)
@@ -62,6 +62,14 @@
# define __ASSUME_VFORK_SYSCALL1
#endif
+/* Starting with version 2.6.4-rc1 the getdents syscall returns d_type
+ *information as well and in between 2.6.5 and 2.6.8 most compat wrappers
+ * were fixed too. Except s390{,x} which was fixed in 2.6.11.
*/
+#if (__LINUX_KERNEL_VERSION = 0x020608 !defined __s390__) \
+|| (__LINUX_KERNEL_VERSION = 0x02060b defined __s390__)
+# define __ASSUME_GETDENTS32_D_TYPE 1
+#endif
+
/* These features were surely available with 2.4.12. */
#if __LINUX_KERNEL_VERSION = 132108 defined __mc68000__
# define __ASSUME_MMAP2_SYSCALL1
___
uClibc-cvs mailing list
[EMAIL PROTECTED]
http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs
___
RE: 10/04 snapshot good -rc2 material.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Reutner-Fischer Sent: den 6 oktober 2008 10:24 To: Rob Landley Cc: uclibc@uclibc.org Subject: Re: 10/04 snapshot good -rc2 material. On Sun, Oct 05, 2008 at 03:35:50AM -0500, Rob Landley wrote: For what it's worth, using the linuxthreads.old stuff, the 10/04 nightly Unfortunately i have _no_ idea what revision that would be. snapshot built for armv4l, armv5l, i586, i686, x86-64, m68k, mips, mipsel, sh4, powerpc, and sparc. I've test booted the arm and mips variants, and should have time to poke at the others in the morning. It seems like good -rc2 candidate material, so I've attached my old busybox release script for Bernhard's use, modified to work for uClibc instead. It's based on an email from Erik about how he used to cut releases, so this is how the existing Thanks for the release script. I've half a dozend of fixes queued before the -rc2, i'll try to apply them this evening (in about 10 hours) and then do the rc2. The new maintainer will have to make his own gpg key, and replace the landley.net reference to a URL to his own public key (on a server _other_ than uclibc.org, or it really defeats the purpose of signing the suckers in the first place). The other step to doing an actual release is announcing it on the web page, something that didn't happen for -rc1. Just FYI... I also forgot to bump the version number in the rc1. I'll do this for the rc2. Thanks for the reminder. cheers, Bernhard And do not forget to actually tag the release in the repository... //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: 10/04 snapshot good -rc2 material.
-Original Message- From: Bernhard Reutner-Fischer [mailto:[EMAIL PROTECTED] Sent: den 6 oktober 2008 14:13 To: Peter Kjellerstedt Cc: uclibc@uclibc.org Subject: Re: 10/04 snapshot good -rc2 material. On Mon, Oct 06, 2008 at 02:02:40PM +0200, Peter Kjellerstedt wrote: And do not forget to actually tag the release in the repository... The release will be tagged and will be copied to a new stable branch, yes. Not sure if I made myself clear, but I was meaning tagging -rc2 (i.e., just like the old tag tags/uClibc_0_9_29_rc1 for 0.9.29rc1). //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: Dependencies patch.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Landley
Sent: den 27 september 2008 00:21
To: uClibc@uclibc.org
Subject: Dependencies patch.
I'm building with the rather verbose
make CROSS=${ARCH}- \
KERNEL_HEADERS=${CROSS}/include \
PREFIX=${CROSS}/ \
RUNTIME_PREFIX=/ \
DEVEL_PREFIX=/ $TARGET
So I want to do all install as my target rather than
repeating the line. Unfortunately, with a -j higher than 1,
the install starts in parallel with the all and the build
breaks.
As a result, I did the following patch so i can just do
install and all is implied, and then -j works out nicely
without me having to repeat lots of make variables.
I don't think there are any downsides, but I thought I'd post
it publicly before merging it.
Rob
Sounds like the right thing to do. We have done something
similar in our code since our build system relies on only
having to do make install in all build directories.
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: CLOCK_MONOTONIC substitution for uclibc?
-Original Message-
From: Steven Woody [mailto:[EMAIL PROTECTED]
Sent: den 27 september 2008 03:40
To: Peter Kjellerstedt
Subject: Re: CLOCK_MONOTONIC substitution for uclibc?
On Fri, Sep 26, 2008 at 3:37 PM, Peter Kjellerstedt
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Joakim Tjernlund
Sent: den 26 september 2008 09:14
To: Steven Woody
Cc: uclibc@uclibc.org
Subject: Re: CLOCK_MONOTONIC substitution for uclibc?
On Fri, 2008-09-26 at 13:30 +0800, Steven Woody wrote:
Hi,
I see even though uclibc implemented clock_gettime(clock_id, tp),
it
does not support clock type of CLOCK_MONOTONIC. So if I want some
kind of monotonic time which should not changed by user process (
such as setting of date), what should I do?
Use ticks = times(NULL), NULL can only be used on Linux.
Jocke
We use CLOCK_MONOTONIC with uClibc without any problem...
What version of uClibc are you using, and what architecture?
Here is 0.9.29, are you sure you are using it without problem? Below
is from 0.9.29's code
(uClibc-0.9.29/libc/sysdeps/linux/common/clock_gettime.c):
int clock_gettime(clockid_t clock_id, struct timespec* tp)
{
struct timeval tv;
int retval = -1;
switch (clock_id) {
case CLOCK_REALTIME:
retval = gettimeofday(tv, NULL);
if (retval == 0) {
TIMEVAL_TO_TIMESPEC(tv, tp);
}
break;
default:
errno = EINVAL;
break;
}
return retval;
}
What version are you using? Thanks.
-
narke
You missed the following three lines above that code:
#ifdef __NR_clock_gettime
_syscall2(int, clock_gettime, clockid_t, clock_id, struct timespec*, tp);
#else
Thus, the use of CLOCK_MONOTONIC with uClibc relies on clock_gettime()
being available as a system call from the kernel (which it obviously
is in the 2.6 kernel we use).
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: CLOCK_MONOTONIC substitution for uclibc?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joakim Tjernlund Sent: den 26 september 2008 09:14 To: Steven Woody Cc: uclibc@uclibc.org Subject: Re: CLOCK_MONOTONIC substitution for uclibc? On Fri, 2008-09-26 at 13:30 +0800, Steven Woody wrote: Hi, I see even though uclibc implemented clock_gettime(clock_id, tp), it does not support clock type of CLOCK_MONOTONIC. So if I want some kind of monotonic time which should not changed by user process ( such as setting of date), what should I do? Use ticks = times(NULL), NULL can only be used on Linux. Jocke We use CLOCK_MONOTONIC with uClibc without any problem... What version of uClibc are you using, and what architecture? //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: cris/crisv32 brokeness
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan de Konink Sent: den 7 september 2008 01:44 To: Stefan de Konink Cc: uclibc@uclibc.org Subject: Re: cris/crisv32 brokeness -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan de Konink schreef: I was unable to test it with pthreads yet, I'll come back to that. Pthread seems to work. I want to fix the native memcpy too, I would love some feedback. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjDFbQACgkQYH1+F2Rqwn3BagCfX1ttIcsIAqIpK4lnOKLGstly u4gAn1apsLqp3BZktx4uxqe0fnrrADpX =Cry5 -END PGP SIGNATURE- ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc I have committed your fix for crti.S now (in a way that makes it work for CRISv10 as well). I have also committed newer versions of memcpy.c and memset.c for CRIS which I hope will fix the problems you have been having with them. I say hope since I do not have a new enough compiler to verify that the problems are actually solved. //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: pthreads stress test hangs on read() returning EINTR
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chase Douglas Sent: den 19 september 2008 22:21 To: Chase N Douglas Cc: uclibc@uclibc.org Subject: Re: pthreads stress test hangs on read() returning EINTR On Sep 19, 2008, at 4:05 PM, Chase N Douglas wrote: I believe I have found the issue. Suppose there are threads A and B. Thread A is running and is in the critical section of malloc() where locks are held to manage the heap and such. A context switch then occurs before thread A can relinquish the malloc locks. Thread B now attempts to fork. After forking, the parent process (still thread B) continues as normal, but the new child process immediately attempts to free the manager thread resources as it's no longer needed. At this point, the child process attempts to grab the malloc locks to free the memory, but it sees that someone is holding the lock (what used to be thread A). We now have a deadlock since even if thread A relinquishes the lock, it's in a separate process now with a separate virtual memory space. The lock state in the child process will never be relinquished. For this reason, such locks should be held before forking, the parent process after the fork should relinquish them, and the child process after the fork should reinitialize them. However, there are many locks in uClibc and not a single one is managed in this way before and after forking. Shouldn't every single lock be dealt with before and after forking, or am I missing something here? After a second glance I see that the only locks this applies to are pthread_mutex_t locks and other types derived from pthread_mutex_t locks. Inside uClibc itself this seems to be only malloc locks and regex locks. I will be trying to put together a patch that will take care of both of these types of locks when forking. Thanks -- Chase Douglas IBM Linux Technology Center [EMAIL PROTECTED] (614) 456-0455 Please take a look at http://uclibc.org/lists/uclibc/2008-March/019187.html which reported this problem half a year ago... //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: [PATCH] use 36 byte buffer in md5 instead of 120, shrink code
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Denys Vlasenko Sent: den 13 juni 2008 17:46 To: uclibc@uclibc.org Subject: Re: [PATCH] use 36 byte buffer in md5 instead of 120, shrink code On Friday 13 June 2008 17:45, Denys Vlasenko wrote: md5 crypt stores result in the form $1$xxx$yNUL where xxx is salt (up to 8 chars) and yyy is hash (22 chars). Using 120 bytes buffer for it is excessive. The patch also replaces e.g. strcat(passwd,$) which writes $ between xxx and above with one-byte store, which is shorter. __md5_to64 is made to return advanced pointer, eliminating the need to do it at call sites. Size: text data bss dec hex filename - 1905 0 1202025 7e9 libcrypt/md5.o + 1879 0 361915 77b libcrypt/md5.o Run tested: TEST_EXEC crypt/ crypt TEST_DIFF crypt/ crypt.out crypt.out.good TEST_EXEC crypt/ md5c-test TEST_EXEC crypt/ crypt_glibc TEST_DIFF crypt/ crypt_glibc.out crypt.out.good TEST_EXEC crypt/ md5c-test_glibc Please review. Now even with patch actually attached. -- vda You changed the type of the second argument to __md5_to64() from unsigned long to unsigned, but in __md5_crypt() you are still passing it l (stupid variable name) which is unsigned long. //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: sysconf(_SC_MONOTONIC_CLOCK) problem
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Will Wagner
Sent: den 12 juni 2008 20:36
To: uclibc@uclibc.org
Subject: sysconf(_SC_MONOTONIC_CLOCK) problem
Hello,
I am using uclicb 0.9.29 on Arm built with buildroot
I want to use monotonic clock support and to test that that
functionality exists I try the following bit of code:
long x = sysconf(_SC_MONOTONIC_CLOCK);
bool hasMonotonic = x = 200112L;
However when I run this sysconf return -1.
Looking at the code it appears this happens if __NR_clock_getres is not
defined. However looking at the kernel headers I think it is defined
as:
#define __NR_clock_getres (__NR_SYSCALL_BASE+264)
in unistd.h
If I run this code:
if (syscall(__NR_clock_getres, CLOCK_MONOTONIC, NULL) 0)
{
printf(syscall failed %d, errno);
return 0;
}
if (clock_getres(CLOCK_MONOTONIC, NULL) 0)
{
printf(clock_getres failed %d, errno);
return 0;
}
Then both calls succeed so the kernel supports this.
From this I assume that uclibc is compiled as if __NR_clock_getres is
not defined. Does that sound right?
I have looked for configuration options and can not find any for this.
How can I enable this?
Thanks,
Will.
The problem is that someone added the check for __NR_clock_getres
after I added the support for _SC_MONOTONIC_CLOCK. Unfortunately
they forgot to add an inclusion of sys/sycall.h which means
__NR_clock_getres will never be defined...
I just committed the following patch to the uClibc repository
which should correct the situation:
Index: libc/unistd/sysconf.c
===
--- libc/unistd/sysconf.c (revision 18424)
+++ libc/unistd/sysconf.c (working copy)
@@ -27,6 +27,7 @@
#include stdlib.h
#include time.h
#include unistd.h
+#include sys/syscall.h
#include sys/sysinfo.h
#include sys/types.h
#ifdef __UCLIBC_HAS_REGEX__
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: [RFC] build system replacement
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Fischer Sent: den 3 juni 2008 10:29 To: Bernd Schmidt Cc: uClibc Subject: Re: [RFC] build system replacement On Sun, Jun 01, 2008 at 05:50:41PM +0200, Bernd Schmidt wrote: Bernhard Fischer wrote: I hope i improved the situation a bit now (if you use r22158 and later). We honour both all our prerequisites (if your compiler groks what we mean to ask for in our gcc-ism) as well as the used CC and flags. I consider this fixed, issue closed, nothing to see here, please move on (or holler if i broke something) :) I've done a bit of digging, and found the cause of two problems. 1. So far, only libc-so-y and libc-a-y are tracked. This needs to be extended to handle all the other libraries, including ld.so. 2. The CFLAGS passed to the compiler have changed in some cases. Previously, when compiling ldso/libdl/libdl.c, $^ used to be ldso/libdl/libdl.c; it is now ldso/libdl/libdl.c FORCE, which means that $(CFLAGS-$(notdir $(^D)) no longer does the right thing: $(notdir $(^D)) is now libdl .. There's also $(CFLAGS-$(notdir $)) in the command line, which doesn't work for this case, since it expands to ldso/libdl/; note the prefix ldso/ and the trailing slash. We could fix this by using $(D) instead of $(^D) in the above. Also, maybe it makes sense to clean up the CFLAGS to always mention the full path without trailing slash. I see that you already took care of this, many thanks. We still have a problem, though. Consider HAVE_SHARED set (i.e. ldso is built) and also some thread variant selected. Build. Turn off thread-support. make clean make; bummer. Suddently there is no rule to make include/bits/pthreadtypes.h (anymore). We recorded this header as a prereq in the first build, but of course turning off thread-support breaks this horribly. A make realclean obviously would bypass this, but either we need dummy-rules for conditional headers like this or do something else to drop those now unavailable prerequisites. Something along what gcc's -MP option does? I'll think about this some more, but perhaps somebody has an opinion or an idea.. :) //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: ldso libdl dl_cleanup issue - Possible Fix
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin Day
Sent: den 15 maj 2008 17:54
To: uClibc
Subject: ldso libdl dl_cleanup issue - Possible Fix
I distantly remember swinging at everything in sight trying to find
and resolve this problem.
This happened on a number of projects and is shown by valgrind, but
I've historically got from uClibc that it was X Project's problem
and when I went to X Project they said it was uClibc's problem.
So, I was recently looking at the same problem again, this time with
abiword as the X project.
I got the usual:
==2807== Invalid read of size 4
==2807==at 0x4600D8C: dl_cleanup (in /lib/libdl-0.9.28.so)
==2807==by 0x4000ADC: (within /lib/ld-uClibc-0.9.28.so)
==2807==by 0x4B4E021: exit (in /lib/libuClibc-0.9.28.so)
==2807==by 0x4B2C46D: __uClibc_main (in /lib/libuClibc-0.9.28.so)
==2807==by 0x8171D1F: _start (in /bin/abiword)
==2807== Address 0x5a0f96c is 4 bytes inside a block of size
24 free'd
==2807==at 0x401933C: free (in
/toolchain/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==2807==by 0x4600C8A: (within /lib/libdl-0.9.28.so)
==2807==by 0x4600D8B: dl_cleanup (in /lib/libdl-0.9.28.so)
==2807==by 0x4000ADC: (within /lib/ld-uClibc-0.9.28.so)
==2807==by 0x4B4E021: exit (in /lib/libuClibc-0.9.28.so)
==2807==by 0x4B2C46D: __uClibc_main (in /lib/libuClibc-0.9.28.so)
==2807==by 0x8171D1F: _start (in /bin/abiword)
again, dl_cleanup seems to be reading unallocated memory
according to valgrind.
After recompiling uClibc with debug symbols, I noticed that it was
caused by two lines in: uClibc-0.9.28.3/ldso/libdl/libdl.c
Line 136: do_dlclose(d, 1);
and in depth, Line 578: free(handle);
Considering that handle was being used during this entire process it
should be allocated..
I decided to look at the logic of the dl_cleanup function and the
do_dlclose function.
Here is a simple explanation of the problem I see:
dl_cleanup will call do_dlclose with the pointer d
Inside of do_dlclose, d will ultimately get free'd
After do_dlclose finishes executing, the for loop from dl_cleanup will
then take the pointer d and move it to the next pointer.
And this is where I am confused, if d was free'd by the do_dlclose
function, then how can it use the d pointer to iterate along the
next location?
So it makes sense that d(NULL)-(Next Pointer) generates an invalid
read according to valgrind.
To test this, I changed the contents of dl_cleanup to:
{
struct dyn_elf *d = _dl_handles;
struct dyn_elf *n;
if (d){
n = d-next;
do_dlclose(d, 1);
while (n){
d = n;
n = d-next;
do_dlclose(d, 1);
}
}
}
I then installed libdl.so, and re-ran valgrind on abiword and the
invalid read no longer appeared.
Does this sound right or is there some loophole in my logic or some
aspect of do_dlclose(..) I am missing?
--
Kevin Day
From a quick look at the code in ldso/libdl/libdl.c I would say
that your assessment is correct. Here is a cleaner solution (this
is based on dl_cleanup() from SVN, not the 0.9.28.3 version):
void dl_cleanup(void)
{
struct dyn_elf *d;
struct dyn_elf *n;
for (d = _dl_handles; d; d = n) {
n = d-next_handle;
do_dlclose(d, 1);
}
}
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: NPTL merge: almost ready to start
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carmelo Amoroso Sent: den 19 april 2008 21:22 To: uclibc Subject: NPTL merge: almost ready to start Hi All, just to inform all of you that I have successfully tested the nptl branch on sh4 after my latest trunk-branch merge. I'd like to check something else, then, asap, I'd like to start merging the branch-trunk so that finally we'll complete a so long still pending work. Please be patient due to my others duties with my work, but this is one of my top priorities in the next months. Best regards, Carmelo Btw, make sure you tag the current state of the uClibc repository before you start merging so that we have something to refer to if something breaks in the process. //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: [PATCH] splice, vmsplice and tee for i386
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Fischer Sent: den 21 april 2008 14:21 To: Timo Teräs Cc: uclibc@uclibc.org Subject: Re: [PATCH] splice, vmsplice and tee for i386 On Mon, Apr 21, 2008 at 12:33:59PM +0300, Timo Teräs wrote: Hi, splice et al for i386. Against svn trunk. Ah, yes. We should also see if using some of the new syscalls help busybox. I'll apply this patch in a few days unless i hear something controversial. thanks and cheers, Bernhard Any particular reason to uncomment sync_file_range() in fcntl.h? It does not seem to be part of the patch. Also, you might as well take the latest fcntl.h from glibc while at it to get a couple of missing defines (unrelated to splice). //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: uClibc compiler without stropts.h
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Denys Vlasenko Sent: den 21 april 2008 07:57 To: uclibc@uclibc.org Subject: Re: uClibc compiler without stropts.h On Monday 21 April 2008 07:43, xrin oscar wrote: Hi, is there any reason for leaving out stropts.h file in uclibc compiler's include folder?? uclibc is not a compiler. -- vda The reason there is no stropts.h in uClibc is because uClibc does not support STREAMs and thus there is no reason to provide it as it would be of no use anyway. //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: svn commit: trunk/uClibc/ldso/ldso
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: den 9 mars 2008 08:07
To: [EMAIL PROTECTED]
Subject: svn commit: trunk/uClibc/ldso/ldso
Author: carmelo
Date: 2008-03-08 23:07:20 -0800 (Sat, 08 Mar 2008)
New Revision: 21278
Log:
Khem Raj [EMAIL PROTECTED] writes:
While compiling trunk on ARM with GCC 4.2 and enabling
LDSO_GNU_HASH_SUPPORT I stumbled upon this problem.
GCC made a call to libgcc function
__aeabi_uidivmod()-__div0()-__raise() and raise is not yet
compiled in at the time of compiling ldso
so I got well known undefined symbol __raise problem
This patch uses the do_rem () macro to do the same operation.
Modified:
trunk/uClibc/ldso/ldso/dl-hash.c
Changeset:
Modified: trunk/uClibc/ldso/ldso/dl-hash.c
===
--- trunk/uClibc/ldso/ldso/dl-hash.c 2008-03-08 21:33:40 UTC
(rev 21277)
+++ trunk/uClibc/ldso/ldso/dl-hash.c 2008-03-09 07:07:20 UTC
(rev 21278)
@@ -204,11 +204,12 @@
unsigned int hashbit1 = hash (__ELF_NATIVE_CLASS - 1);
unsigned int hashbit2 = ((hash tpnt-l_gnu_shift)
(__ELF_NATIVE_CLASS - 1));
-
+ unsigned long rem;
+ do_rem (rem, hash, tpnt-nbucket);
_dl_assert (bitmask != NULL);
if (unlikely((bitmask_word hashbit1) (bitmask_word
hashbit2) 1)) {
- Elf32_Word bucket = tpnt-l_gnu_buckets[hash %
tpnt-nbucket];
+ Elf32_Word bucket = tpnt-l_gnu_buckets[rem];
if (bucket != 0) {
const Elf32_Word *hasharr =
tpnt-l_gnu_chain_zero[bucket];
You should move the calculation of rem to within the if statement,
since the modulo operation is time consuming and the if statement
is marked as unlikely(), i.e.:
if (unlikely((bitmask_word hashbit1) (bitmask_word
hashbit2) 1)) {
Elf32_Word bucket;
unsigned long rem;
do_rem(rem, hash, tpnt-nbucket);
bucket = tpnt-l_gnu_buckets[rem];
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
[PATCH] Make libc/inet/resolv.c use poll() rather than select()
I intend to apply the patch below unless anyone has any objections.
The reason is that if one has used setrlimit(RLIMIT_NOFILE, x) with
x 1024, using the FD_ macros will cause memory corruptions if a
file descriptor = 1024 happens to be used since the macros are
limited to FD_SETSIZE (which is 1024).
This is basically the same solution as is already used in
libpthread/linuxthreads.old/manager.c (the only other place in the
uClibc code where select() is used).
Index: uClibc/libc/inet/resolv.c
===
--- uClibc/libc/inet/resolv.c (revision 20841)
+++ uClibc/libc/inet/resolv.c (working copy)
@@ -140,6 +140,7 @@
#include stdio.h
#include signal.h
#include errno.h
+#include sys/poll.h
#include sys/socket.h
#include sys/types.h
#include sys/time.h
@@ -157,6 +158,14 @@
#include sys/un.h
#include bits/uClibc_mutex.h
+/* poll() is not supported in kernel = 2.0, therefore if __NR_poll is
+ * not available, we assume an old Linux kernel is in use and we will
+ * use select() instead. */
+#include sys/syscall.h
+#ifndef __NR_poll
+# define USE_SELECT
+#endif
+
__UCLIBC_MUTEX_EXTERN(__resolv_lock);
libc_hidden_proto(memcpy)
@@ -185,6 +194,7 @@
libc_hidden_proto(inet_pton)
libc_hidden_proto(inet_ntop)
libc_hidden_proto(connect)
+libc_hidden_proto(poll)
libc_hidden_proto(select)
libc_hidden_proto(recv)
libc_hidden_proto(send)
@@ -721,8 +731,12 @@
unsigned char **outpacket, struct
resolv_answer *a)
{
int i, j, len, fd, pos, rc;
+#ifdef USE_SELECT
struct timeval tv;
fd_set fds;
+#else
+ struct pollfd fds;
+#endif
struct resolv_header h;
struct resolv_question q;
struct resolv_answer ma;
@@ -851,6 +865,7 @@
send(fd, packet, len, 0);
+#ifdef USE_SELECT
FD_ZERO(fds);
FD_SET(fd, fds);
tv.tv_sec = REPLY_TIMEOUT;
@@ -862,6 +877,17 @@
* to next nameserver on queue */
goto tryall;
}
+#else
+ fds.fd = fd;
+ fds.events = POLLIN;
+ if (poll(fds, 1, REPLY_TIMEOUT * 1000) = 0) {
+ DPRINTF(Timeout\n);
+
+ /* timed out, so retry send and receive,
+* to next nameserver on queue */
+ goto tryall;
+ }
+#endif
len = recv(fd, packet, 512, 0);
if (len HFIXEDSZ) {
//Peter
___
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: svn commit: trunk/uClibc/libc/misc/mntent
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: den 10 november 2007 07:43 To: [EMAIL PROTECTED] Subject: svn commit: trunk/uClibc/libc/misc/mntent Author: kraj Date: 2007-11-09 22:42:45 -0800 (Fri, 09 Nov 2007) New Revision: 20406 Log: Do not return error when fprintf returns 0 in addmntent(). fprintf is considered failing if the return is less than 0 Modified: trunk/uClibc/libc/misc/mntent/mntent.c Changeset: Modified: trunk/uClibc/libc/misc/mntent/mntent.c === --- trunk/uClibc/libc/misc/mntent/mntent.c2007-11-10 03:24:21 UTC (rev 20405) +++ trunk/uClibc/libc/misc/mntent/mntent.c2007-11-10 06:42:45 UTC (rev 20406) @@ -98,11 +98,8 @@ if (fseek(filep, 0, SEEK_END) 0) return 1; - if (fprintf (filep, %s %s %s %s %d %d\n, mnt-mnt_fsname, mnt-mnt_dir, - mnt-mnt_type, mnt-mnt_opts, mnt-mnt_freq, mnt-mnt_passno) 1) - return 1; - - return 0; + return (fprintf (filep, %s %s %s %s %d %d\n, mnt-mnt_fsname, mnt-mnt_dir, + mnt-mnt_type, mnt-mnt_opts, mnt-mnt_freq, mnt-mnt_passno) 0 ? 1 : 0); } char *hasmntopt(const struct mntent *mnt, const char *opt) Under what circumstances can fprintf() return 0 given that the format string contains spaces, %d and a line feed? //Peter ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
