7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1

Andrew Reilly andrew at areilly.bpc-users.org
Tue Jan 22 02:10:33 PST 2008


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).

If you think that it might help to track things down, I can jump
forward to -STABLE again and rebuild at least all of mred's
dependencies, but that's going to be a slow process...

Reckon I'll give that a go.  No point staying in the past, now
that we know where abouts the breakage occurred.

Cheers,

-- 
Andrew


More information about the freebsd-stable mailing list