7-STABLE regression that breaks lang/drscheme is
marius at alchemy.franken.de
Tue Jan 22 14:05:55 PST 2008
On Tue, Jan 22, 2008 at 09:10:14PM +1100, Andrew Reilly wrote:
> Hi Marius,
> On Tue, 22 Jan 2008 10:33:27 +0100
> Marius Strobl <marius at alchemy.franken.de> wrote:
> > The __gthread_active_p(), which returns false positives prior
> > to the current version of gthr-posix.h, isn't only used in
> > libstdc++ but also in headers that are installed beneath
> > /usr/include/c++. So the code in those headers compiled into
> > an existing binary which was built prior to the gthr-posix.h
> > fix still might erroneously determine that it's running in a
> > threaded environment while f.e. libstdc++ does not, causing
> > the problems you see. Did you try a mred built on a stock
> > 7-STABLE?
> When it first stopped working (around the 11th, from memory), my
> first approach was to rebuild it (over and over, and attempt to
> debug it...) No joy that way. It's only since I reverted to
> the earlier version of FreeBSD that it's started working again.
> As part of the attempt to make mred work again, I re-built
> *all* of the ports that I have installed (some 900-odd), so
> all of the libraries in /usr/local/lib are post-15 Jan., and
> have whatever effect the change introduces. Perhaps that is
> why epiphany has gone unstable on me (seems to be complaining
> about failing to connect to gnomevfs). I suspect that mred
> wasn't minding false-positives before, because it's been
> configured/compiled with pthreads enabled (for the benefit of
> Mesa/OpenGL, apparently).
Ok, in your previous mail you talked about an "exisiting binary"
so I assumed you haden't tried with a recompiled one or a
recompiled one didn't exhibit the problem. Anyway, you're right
and I've overlooked that mred is threaded anyway so in this case
it shouldn't matter if __gthread_active_p() prevously returned
false-positives or not. The only way I currently can think of
the new __gthread_active_p() causing problems would be if now it
returned false-negatives. So far I can't reproduce such a problem
nor see how that could happen though. It would help if you could
debug where mred craches and what __gthread_active_p() returned
in this case.
More information about the freebsd-ports