Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Jan 2008 10:33:27 +0100
From:      Marius Strobl <marius@alchemy.franken.de>
To:        Andrew Reilly <andrew@areilly.bpc-users.org>
Cc:        Joseph Koshy <jkoshy@freebsd.org>, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org
Subject:   Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
Message-ID:  <20080122093327.GB38360@alchemy.franken.de>
In-Reply-To: <20080122094405.230a0856@duncan.reilly.home>
References:  <20080122094405.230a0856@duncan.reilly.home>

next in thread | previous in thread | raw e-mail | index | archive | help
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 1.1.1.8.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
7-STABLE?

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

Marius




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080122093327.GB38360>