24 May 15:21
22 Apr 20:47
4 Apr 19:04
[PATCH] makefile: accept more ARM architecture strings
Enrico Scholz <enrico.scholz <at> informatik.tu-chemnitz.de>
2012-04-04 17:04:22 GMT
2012-04-04 17:04:22 GMT
[https://github.com/ensc/dietlibc/commit/e9050510662bc6dcfd13dd1be136ad0700231d63] E.g. Fedora buildsystem uses armv7hl which is not matched by current string: https://bugzilla.redhat.com/show_bug.cgi?id=800601 Enrico
4 Apr 19:02
[PATCH] implemented fstatat() syscall + testsuite
Enrico Scholz <enrico.scholz <at> informatik.tu-chemnitz.de>
2012-04-04 17:02:21 GMT
2012-04-04 17:02:21 GMT
[See https://github.com/ensc/dietlibc/commit/25938b345a2072535930fd354cb5675df1262336 resp. look in the 'rebase' branch for the actual patch] fstatat(2) seems to be implemented either by * __NR_fstatat (only MIPS?) * __NR_fstatat64 (32 bit archs) * __NF_newfstatat (64 bit archs) Changeset adds this syscall and a test case which checks some other *at() functions too Verified for i386, x86_64 + armv5. Enrico
4 Apr 12:14
Re: NaCl
Jorge Almeida <jjalmeida <at> gmail.com>
2012-04-04 10:14:03 GMT
2012-04-04 10:14:03 GMT
On Wed, Apr 4, 2012 at 8:50 AM, R.L. Horn <lists <at> eastcheap.org> wrote: > On Wed, 4 Apr 2012, Jorge Almeida wrote: > >> Any idea whether it is possible to compile NaCl against dietlibc? > > > Apparently so. > > From the source directory: > > cd okcompilers > mv c c.orig > sed 's/^gcc/diet gcc/' c.orig > c > mv cpp cpp.orig > touch cpp > > Then build as usual. (Actually, I replaced the contents of "c" with a > single diet gcc invocation, but the above should allow the tests to proceed > as normal.) > Done, with success. > Obviously, you won't get the C++ wrappers, but I'm assuming you don't want > those anyway. Correct. Thanks!(Continue reading)
4 Apr 02:53
31 Mar 23:45
openssh
Jorge Almeida <jjalmeida <at> gmail.com>
2012-03-31 21:45:17 GMT
2012-03-31 21:45:17 GMT
Compiling openssh is choking on utmpx: CC="/opt/bin/diet -Os gcc -pipe -fomit-frame-pointer -mtune=core2 -mfpmath=sse -nostdinc -D_GNU_SOURCE -D_BSD_SOURCE" CPPFLAGS="-I/extra/zlib/include -I/extra/openssl/include" ./configure --prefix=/extra/openssh --with-ipaddr-display --with-4in6 --with-ssl-dir=/extra/openssl --with-zlib=/extra/zlib/lib --with-privsep-user=sshd --with-md5-passwords --disable-etc-default-login --disable-lastlog Configuring exits 0. make fails: loginrec.c:561:1: warning: ‘u_int’ is deprecated [-Wdeprecated-declarations] loginrec.c: In function ‘construct_utmpx’: loginrec.c:791:10: error: ‘ut’ undeclared (first use in this function) loginrec.c:791:10: note: each undeclared identifier is reported only once for each function it appears in loginrec.c: In function ‘utmpx_perform_login’: loginrec.c:1033:31: error: ‘ut’ undeclared (first use in this function) make: *** [loginrec.o] Error 1 Adding "--disable-utmpx" to the config line yields success. Any idea? And, if not: is utmpx really usefull in a personal workstation, at least when the utmp functionallity is present? openssh-5.9p1 openssl-1.0.1 zlib-1.2.6(Continue reading)
23 Feb 13:54
clone() prototype
Frank Bergmann <dietlibc <at> tuxad.com>
2012-02-23 12:54:30 GMT
2012-02-23 12:54:30 GMT
Hi, the current prototype of clone() as of 2011-12-20 (sched.h) still seems to be wrong. Environment is i386, different kernels and gcc. dietlibc declares the function prototype of the first argument of clone() as int *(*fn)(void*) but actually uses int (*fn)(void*) as the following code snippet shows. $ gcc -Os -Wall -o clonefunctest clonefunctest.c # glibc uses int (*fn)(void *) $ ./clonefunctest child_status=123 wait=Success $ diet -Os gcc -Os -Wall -o clonefunctest clonefunctest.c # still return int and not int* clonefunctest.c: In function ?measure?: clonefunctest.c:24: warning: return makes pointer from integer without a cast /opt/diet/lib-i386/libc.a(vprintf.o): In function `vprintf': vprintf.c:(.text+0x20): warning: warning: the printf functions add several kilobytes of bloat. $ ./clonefunctest child_status=123 wait=Success $ diet -Os gcc -Os -Wall -o clonefunctest2 clonefunctest2.c # return int* as declared in sched.h /opt/diet/lib-i386/libc.a(vprintf.o): In function `vprintf': vprintf.c:(.text+0x20): warning: warning: the printf functions add several kilobytes of bloat. $ ./clonefunctest2(Continue reading)
10 Feb 16:43
Broken Tarball Links
Jay Sullivan <notfed <at> gmail.com>
2012-02-10 15:43:57 GMT
2012-02-10 15:43:57 GMT
Hi, The links under "Recent News" appear to be broken (and appear to have been for a while now.) For example, http://www.kernel.org/pub/linux/libs/dietlibc/dietlibc-0.32.tar.bz2 is a broken link. And as far as I can tell, all of the tarball links are broken. I noticed the most recent version on kernel.org appears to be located at: http://www.kernel.org/pub/linux/libs/dietlibc/dietlibc-0.29.tar.gz. Thanks, Jay Sullivan
23 Dec 15:27
Re: unlinkat
Jorge Almeida <jjalmeida <at> gmail.com>
2011-12-23 14:27:30 GMT
2011-12-23 14:27:30 GMT
On Fri, Dec 23, 2011 at 11:23 AM, Indan Zupancic <indan <at> nul.nu> wrote: > > In my opinion libc's task is to give access to all system calls. > Linux has had *at() system calls for a while now, and in 5 years > it will had it for ages. Please add the system call stubs. > > I wouldn't go glibc's way of adding emulator code in case the > system calls are not supported by the kernel. > > Dietlibc is linux-only, it should at least try to support all > (sensible) Linux system calls. And it's not worth a compile-time > option as barely any code is added. > Most programs are made by people for their own use, only a small minority is of general interest and worth of distribution (that's what I read, anyway it makes sense). For me (and, I'm guessing, for most home-users), the advantage of dietlibc (besides efficiency and small footprint) is the compile-and-forget feature, that is, the immunity to general software upgradings that can go wrong. I don't care much for the portability, I always recompile before using in another computer, just for the small benefit of specific CFLAGS. So, either it compiles or it doesn't. In case one just copies a program to another computer (assuming the program was compiled with generic flags) and it crashes or worse, that's the programmer's fault. He should make sure his program exits when a syscall fails. So, I also think dietlibc should support system calls that are supported by the kernel, but might just ignore the ones the kernel does not support. Jorge Almeida(Continue reading)
RSS Feed