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

[Aleksej Saushev <asau%inbox.ru@localhost>]

Greg Troxel <gdt%ir.bbn.com@localhost> writes:

> [followup changed to tech-pkg, as this is larger in scope than the usual
> pkgsrc-changes discussion]
>
> Matthew Mondor <mm_lists%pulsar-zone.net@localhost> writes:
>
>> 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.
>
> I realize it's been unthreaded in pkgsrc historically.  But I meant that
> in the larger free software world, it seems that the threaded version is
> considered more normal.
>
> (I see this has been reverted for now, but we still need to figure out
> what to do.)
>
> So where we are, as I see it:
>
>   threads being enabled is currently dependent on platform.  That
>   doesn't make sense, and is counter to the pkgsrc way.  (It probably
>   means that ecl fails on Darwin, but maybe it's broken anyway.)

I don't understand what was the reason to do it in a platform-dependent way.

>   It seems we have a situation where many uses of libgc need or desire
>   threads, perhaps more than half (but it's not clear), but there is at
>   least one known case (ecl) where that causes trouble.  But, the most
>   prominent user of ecl is using it threaded and avoiding the bug -- so
>   the idea that boehm-gc should not be built threaded because of ecl
>   does not have a lot of support.  The PR does not contain other
>   examples.

I'm using it unthreaded exactly because I've never seen threaded version
in functional state. Thus it is the opposite way actually.

> The other question is who is going to do what work, and in what stages.
> So I'd say that if anyone wants to create a boehm-gc-nothreads package
> (without requiring it to not conflict), it's then ok to flip boehm-gc
> back to threads, and any depending packages that have trouble with that
> can then just move to the nothreads version.  That will result in being
> able to install either the threaded or the nonthreaded version.  This is
> not really a regression, because right now packages can't be built with
> thread support, so we essentially have a forced option.  Having two that
> couldn't be installed together would be more flexible than what we have
> now, and more useful for binary package users.
>
> Then, if someone wants to change the nothreads version to not conflict,
> that would be great.  But I don't think we should hold up incremental
> progress based on that not being done.

I'm testing the state of threads support with the new release,
but I cannot do it instantly.


-- 
HE CE3OH...