From: mitch@spuddy.uucp (Mitchum Dsouza) Subject: Re: xdaliclock on Linux Date: Wed, 1 Sep 1993 21:25:09 GMT
> From: Andrew Tefft <teffta@engr.dnet.ge.com>
> Subject: xdaliclock on Linux
> Date: 15 Aug 1993 20:07:51 -0400
> Reply-To: teffta@engr.dnet.ge.com
>
> Has anyone tried to compile xdaliclock under Linux?
Yup I have.
>
> I got v. 1.05 and compiled it; it just apparently did nothing. I
> started it up in gdb and hit control-c and it appeared to be "stuck"
> at a select() call. So I used -DNO_SELECT as suggested in the Imakefile,
> same result.
Nope it is not hanging in select.
>
> I wanted the debugging symbols so I compiled with -g... and it worked!
> I seem to remember that this forces static linking so I tried -static
> instead of -g and it continued to work.
>
> While I should be satisfied that it works, it is about 10x the size
> it should be.
>
> So, has anyone else run into something like this?
Actually the bug is in free() and only happens in for the builtin font.
I am looking into the problem and I suspect will have patches and/or should
be fixed in the next libc (>4.2.2).
To get over this temporarily you can do any *one* of the following.
1) Perform these steps where you extracted the xdaliclock source. This will
give you a shared executable with static versions of only the affected
(broken) functions.
% make xdalicock.o
% ar x /usr/lib/libg.a free.o malloc.o morecore.o
% gcc -s -o xdaliclock -L/usr/X386/lib xdaliclock.o \
free.o malloc.o morecore.o -lX11 -lXext
malloc.o and morecore.o is only required to resolve references in the
debugging version of free.o. If you dont believe me try writing a simple
function free.c with the lines
free (c) {};
and then compile and link with only xdaliclock.o and free.o
2) Don't use the builtin font. I.e. take out the -DBUILTIN_FONT from the
Imakefile and then do
% make clean; xmkmf; make
3) Start xdaliclock with a font other than the builtin
% xdaliclock -fn 10x20
4) Comment out the line in load_builtin_font() (approx line 341) in
xdaliclock.c which says
XDestroyImage (image);
which esentially calls free(). This does _not_ seem to cause memory leaks.
Hope this helps
Mitch
--* Meeeow ! Call Spuddy on (0203) 364436/362560 for FREE mail & Usenet access *