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>