Subject: Re: where is the rxvt-path mentioned in rxvt.mk? - msg#00161

Previous Message by Date: click to view message preview

Re: file descriptor (socket) leakage

On Tue May 27, 2003 at 04:00:02PM +0200, Tomislav Sajdl wrote: > I have a system with embedded linux (uclibc 0.9.16, kernel 2.4.20) and I run > freeswan on it (1.99). Problem is that freeswan ends up with 1024 open > sockets, which makes it to stop working [although it is still running]. > What do you think, what may be the source of the problem? > > I have a reaseon to believe that socket stays unclosed every time whet it is > open toward interface of the system itself (no matter you call close()), > but I cannot say for sure. > > Does anyone have the similar problem? I doubt on uclibc as a source of the > problems. Could you try again with uClibc 0.9.19? -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons--

Next Message by Date: click to view message preview

Re: cvs 20030523-20030524 rpl_malloc problem

On Tue May 27, 2003 at 11:21:00AM +0200, Peter S. Mazinger wrote: > Hello! > > Since the last change in stdlib.h (rpl_malloc) I get following on building > rpm-4.0.4 > /usr/include/stdlib.h:555: syntax error before numeric constant > /usr/include/stdlib.h: In function `rpl_malloc': > /usr/include/stdlib.h:558: invalid lvalue in increment I just checked in this patch for uClibc, which will fix the problem you are seeing. --- include/stdlib.h 23 May 2003 06:42:53 -0000 1.36 +++ include/stdlib.h 27 May 2003 20:13:13 -0000 1.38 @@ -550,14 +550,14 @@ /* Cope with autoconf's broken AC_FUNC_MALLOC macro, which * redefines malloc to rpl_malloc if it does not detect glibc * style returning-a-valid-pointer-for-malloc(0) behavior. This - * calls malloc() as usual, but if N is zero, we allocate and + * calls malloc() as usual, but if __size is zero, we allocate and * return a 1-byte block instead.... sigh... */ -static inline char * rpl_malloc (size_t N) +static __inline void *rpl_malloc (size_t __size) { - if (N == 0) { - N++; + if (__size == 0) { + __size++; } - return malloc (N); + return malloc(__size); } #endif -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons--

Previous Message by Thread: click to view message preview

where is the rxvt-path mentioned in rxvt.mk?

Hi, we are building a small distribution for our own fun based on uClibc and buildroot. Now it's time to get X running but rxvt fails (devpts is mounted): rxvt: can't open pseudo-tty I guess the patch mentioned in rxvt.mk solves that: RXVT_PATCH:=$(SOURCE_DIR)/rxvt-2.6.4.patch Could someone send the patch to me :)? MFG Karsten Kruse -- Homepage, Mac68k, A/UX-Links und Shorties: www.tecneeq.de () Linux/NetBSD-Anleitungen, Forum und Chat: www.newbie-net.de <\/> _/\_ When you are in it up to your ears, keep your mouth shut.

Next Message by Thread: click to view message preview

Dynaminc linking : /usr/i386-linux-uclibc/lib vs /lib

Hi ! I have the following problem : uClibc is installed is /usr/i386-linux-uclibc/ and when I make dynamic linked executables, they need /usr/i386-linux-uclibc/lib/libc.so.0 and /usr/i386-linux-uclibc/lib/ld-uClibc.so.0 Or I make these executables to run on another target, and I whant the libraries to be in /lib. Before compiling uclibc I tried an "export SHARED_LIB_LOADER_PATH=/lib" which is the answer I picked up in the ML archive, but that not resolved my problem )-: What is the way to compile dynamic linked executables in order to allow to be executed on the target environnement ? Thank you very much. Guillaume Betous