On Mon 21 May 2012 07:45, Ken Raeburn raeb...@raeburn.org 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
Hi Ken,
On Mon 21 May 2012 07:45, Ken Raeburn raeb...@raeburn.org 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,
On Tue 22 May 2012 10:17, Andy Wingo wi...@pobox.com 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/
On May 22, 2012, at 03:54, Andy Wingo wrote:
On Mon 21 May 2012 07:45, Ken Raeburn raeb...@raeburn.org 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,
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 is
Ken Raeburn raeb...@raeburn.org 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
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.2
