Re: [Bug-zile] zile-2.4.3: libgc dependence, and a workaround

[Reuben Thomas]

On 23 December 2011 18:33, Nelson H. F. Beebe <address@hidden> wrote:
> While I have been able to install Hans Boehm's libgc on almost all of
> our 25 or so flavors of Unix, MirBSD is an exception.  Today, I tried
> about 10 historical versions of libgc on that platform. Several built,
> but they all core dumped in their validation tests.

As ever, thanks for your detailed report.

> The problem is that zile-2.4.3 (and probably earlier versions) assumes
> that libgc is available, but that is not a good assumption, because
> libgc isn't a standard package on most systems, and as the MirBSD
> experience shows, it may not be buildable.

For the moment, I'm committing to it. I've not yet had a complaint
from a user (unless you really do use MirBSD, in which case, I've had
one complaint!).

> %  diff configure.org configure
> 29701c29701
> < if test "x$enable_debug" != "yes"; then
> ---
>> if test "x$enable_debug" == "xyes"; then

Thanks for this; I've pushed a fix to git for this.

> + #if 0
>    GC_INIT ();
> + #endif
>    set_program_name (argv[0]);

This I can't really countenance as it will result in Zile leaking
space uncontrollably. The only reason that --enable-debug turns this
off is that libgc is not friends with Valgrind in some configurations.

> I hope that the next release of zile can provide a --disable-gc /
> --enable-gc configure option pair, with small changes in configure.ac,
> main.c, and main.h to avoid attempting to include any form of gc.h,
> and trying to invoke GC_INIT (), if --disable-gc has been selected.

There's no way to do that without reintroducing manual memory
management, which would obviate the need for libgc.

MirBSD users & libgc developers need to get together. There's plenty
of software that uses libgc now, and since libgc is widely ported,
getting it on another BSD can't be hard, I hope.

The long-term fix will be the Lua version of Zile, which I'm still
working on stabilising. It doesn't require any non-POSIX APIs, as it
uses Lua's own garbage collector. At the moment it's still a bit of a
pain to build, because of various C to Lua bindings libraries it
needs, but since I am now maintaining all of these, I aim to make it
easier to install using the LuaRocks system. LuaRocks itself is highly
portable, so should work on pretty much any random UNIX-a-like. If
you're subscribed to some form of Zile announcements, you'll see when
I release a beta version of Lua Zile (it's currently still in alpha)
that it's ready for widespread trials.

Thanks again!

-- 
http://rrt.sc3d.org