On May 22, 2012, at 04:17, Andy Wingo wrote:
> These are related. Until recently, the intention was that 7.1 was the
> minimum version, though we supported compilation against 6.8, which is
> the version in Debian stable. As it is, the final 7.2 release was only
> made a couple weeks ago, which i
On May 22, 2012, at 03:54, Andy Wingo wrote:
> On Mon 21 May 2012 07:45, Ken Raeburn writes:
>
>> I've also checked in on master a couple pretty straightforward-looking
>> fixes. I don't know if either would be applicable to the current
>> release.
>
> Thank you very much for these, especially
On Tue 22 May 2012 10:17, Andy Wingo writes:
> I don't recall what the end result was, but it could have been a bug in
> a libffi compiled by that libgc.
By that GCC, I meant; which is really an old fork Apple made of GNU GCC.
Andy
--
http://wingolog.org/
Hi Ken,
On Mon 21 May 2012 07:45, Ken Raeburn writes:
> * Eliminate use of GC_PTR. Looks like it's a holdover from earlier
> versions of libgc. Some versions don't define it, so we do. Apparently
> the 7.2 release defines it, too, which resulted in bug #11500. It turns
> out, too, that some
On Mon 21 May 2012 07:45, Ken Raeburn writes:
> I've also checked in on master a couple pretty straightforward-looking
> fixes. I don't know if either would be applicable to the current
> release.
Thank you very much for these, especially the locking one! How did you
catch the locking bug, jus
Ken Raeburn writes:
> * Require libgc 7.2 or better. Too often the fix to flaky problems
> seems to be "try updating to the latest libgc and see if that fixes
> it", so let's just require it. Or is 7.1 really *that* consistently
> reliable for our use cases on some platforms?
7.2 is required f
After reading the "dynamic ffi and C struct" thread this weekend, I started
thinking, "I wonder if that's really done so as to handle X and Y and Z, and if
we're actually testing it well enough", and got the urge to do another Mac
build, which I hadn't done in a while. After installing libgc 7.
