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

Marius Strobl marius at alchemy.franken.de
Tue Jan 22 02:12:58 PST 2008

On Tue, Jan 22, 2008 at 09:44:05AM +1100, Andrew Reilly wrote:
> Hello again,
> [to recap: drscheme, (which is an IDE that runs under the "mred"
> runtime, built from ports/lang/drscheme (or actually manually
> from a personal copy of that Makefile that builds the current
> release:  372, rather than ver 370 in ports)) worked beautifully
> on my system until I updated to 7-STABLE after 4 Jan.  I track
> -STABLE every week or two.  After that, it segfaults before
> printing or displaying anything, and running under gdb has found
> that it stops in the garbage collector initialization.  I
> haven't raised a PR for this yet because I still think that the
> problem is probably the drscheme FreeBSD configuration that has
> bit-rotted a little, now that FreeBSD has changed slightly.
> Still investigating...  I've cc'd Joseph Koshy, because this
> seems to be somehow related to PR ports/118808.]
> I've done the binary search through CVS, and established that
> the precise file and revision that is causing me (or rather,
> drscheme) grief: src/contrib/gcc/gthr-posix.h marius
> at 5 Jan 22:58.51.  Csupping back to 5 Jan 22:50 is enough to
> make everyting happy again.
> Unfortunately, I'm at a loss to explain how this change could be
> causing an existing binary to run or not, because it changes the
> compiler.  Well, presumably it changes the installed libc.so and
> libstdc++.so, both of which are linked in at run-time (c++ is used
> in mred/drscheme for the wxWidgets GUI).  Indeed, the most recent
> time that I backed this revision of gthr-posix.h out (regressed
> to 5 Jan 22:50), drscheme started to work as soon as the system
> libraries had been installed, before I had rebooted.

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

> Since there hasn't been any other wailing about incompatability
> since this change, my guess is that mred was somehow working
> around the previous FreeBSD behaviour: it has quite a bit of
> low-level platform-specific configuration, since it is a
> language runtime.  The ideal solution will be to figure out how
> to tweak it's FreeBSD compatability to suit the new operation.
> If anyone can offer a hint as to which area I should be looking
> at for configuration knobs, I'd be really grateful.


More information about the freebsd-stable mailing list