7-STABLE regression that breaks lang/drscheme is
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 18.104.22.168.2.1 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