Re: CVS commit: pkgsrc/devel/boehm-gc

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Thu, 01 May 2014 20:30:16 -0400
Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

> So given the bug history, it seems that boehm-gc with threads is likely
> the normal case, and we need to add a boehm-gc-nothreads package, and

Historically in pkgsrc threads were disabled by default for boehm-gc,
until very recently.  The intent of pkg/41893 was originally to enable
threads by default, but then it became evident that some issues existed.

On some Linux distributions, it's indeed now enabled by default (i.e.
on Ubuntu); but I also could not reproduce the same bugs on Linux when
I last tried.

> then drop the thread option from both.  This will mean that needing both
> will fail, and thus the packages that need no-threads can't coexist with
> the regular ones (or the other way around), but absent renaming, that
> seems how it is.

If we also have the nothreads package, I think that ideally it should
be able to coexist, with renaming if possible, like adding a suffix;
i.e.: /usr/pkg/lib/libgc-nothreads.so.1.0.3

> Is there another example besides ecl that has trouble with the threaded
> version?

Unfortunately I don't personally know, as ECL is the only software I use
needing libgc.  If Mono works on NetBSD, it's probably another
candidate to try.  I believe that Inkscape also uses it, but I've not
used that in a while; it's worth testing.  If it doesn't use stdio or
rwlocks, or doesn't use multiple threads, it might also work fine with
a threads-enabled libgc.

It might be a good idea to eventually also write C-only test cases, of
course.

For my use cases I still need ECL with threads, so I build libgc with
threads as well.  My own code avoids stdio and rwlocks and has been
stable that way (a crow-httpd instance currently has 239 days uptime on
a netbsd-5 system).
-- 
Matt