Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Jan 2008 09:44:05 +1100
From:      Andrew Reilly <andrew@areilly.bpc-users.org>
To:        freebsd-stable@freebsd.org, marius@freebsd.org, obrien@freebsd.org, freebsd-ports@freebsd.org, Joseph Koshy <jkoshy@FreeBSD.org>
Subject:   7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
Message-ID:  <20080122094405.230a0856@duncan.reilly.home>

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

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.

Extra data:  ldd mred:
/usr/local/bin/mred:
	libmred3m-372.so => /usr/local/lib/libmred3m-372.so (0x800639000)
	libmzscheme3m-372.so => /usr/local/lib/libmzscheme3m-372.so (0x800a40000)
	libXaw8.so.8 => /usr/local/lib/libXaw8.so.8 (0x800e0f000)
	libXmu.so.6 => /usr/local/lib/libXmu.so.6 (0x800f7c000)
	libXt.so.6 => /usr/local/lib/libXt.so.6 (0x801094000)
	libSM.so.6 => /usr/local/lib/libSM.so.6 (0x8011f4000)
	libICE.so.6 => /usr/local/lib/libICE.so.6 (0x8012fc000)
	libXext.so.6 => /usr/local/lib/libXext.so.6 (0x801416000)
	libGL.so.1 => /usr/local/lib/libGL.so.1 (0x801526000)
	libXft.so.2 => /usr/local/lib/libXft.so.2 (0x8016a2000)
	libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x8017b5000)
	libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x801934000)
	libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x801a67000)
	libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801be1000)
	libglitz.so.1 => /usr/local/lib/libglitz.so.1 (0x801d04000)
	libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x801e2d000)
	libX11.so.6 => /usr/local/lib/libX11.so.6 (0x801f36000)
	libXau.so.6 => /usr/local/lib/libXau.so.6 (0x80213a000)
	libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x80223d000)
	librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x802342000)
	libpng.so.5 => /usr/local/lib/libpng.so.5 (0x80244b000)
	libz.so.4 => /lib/libz.so.4 (0x802571000)
	libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x802686000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x8027a7000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x8029a0000)
	libm.so.5 => /lib/libm.so.5 (0x802b9f000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802cb9000)
	libthr.so.3 => /lib/libthr.so.3 (0x802dc6000)
	libc.so.7 => /lib/libc.so.7 (0x802edc000)
	libXpm.so.4 => /usr/local/lib/libXpm.so.4 (0x8030f9000)
	libXp.so.6 => /usr/local/lib/libXp.so.6 (0x80320a000)
	libXxf86vm.so.1 => /usr/local/lib/libXxf86vm.so.1 (0x803312000)
	libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x803417000)
	libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x803519000)
	libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x80361e000)

ldd mzscheme (which works just fine: it's the command-line
language, without the wxWidgets GUI, but using exactly the same
garbage collector):
/usr/local/bin/mzscheme:
	libmzscheme3m-372.so => /usr/local/lib/libmzscheme3m-372.so (0x800638000)
	libm.so.5 => /lib/libm.so.5 (0x800a07000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800b21000)
	libc.so.7 => /lib/libc.so.7 (0x800d1a000)

Cheers,

-- 
Andrew



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