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! --