>>Hmm, well with respect to my problem, I'm using a pretty recent >>toolchain, with gcc 3.4.4, binutils-2.16.1, glibc-2.3.5, and headers >>from a linux-mips 2.6.11 snapshot. Interestingly, I tried to reproduce >>Bryan's segfault, but could not. That code ran without error when I >>linked with libpthread. Any thoughts? > > > I don't think glibc 2.3.5 worked for mips64. But I haven't checked it > in a long time. Try CVS HEAD of glibc instead. > > Other than that, you're on your own - building glibc is extremely error > prone. > I'm sure it can be error prone, but that isn't the problem here at all. My n32 glibc 2.3.5 compiled and seems to work just fine, and I was able to compile an entire userland around it that has no (other) problems so far as I can tell. By this, I mean "emerge system" in Gentoo terms, which is a pretty good test of whether the toolchain works or not. Furthermore, other programs that are linked against libpthread run without causing a segfault and oops. I'm talking about glib, as in the glib that used to be part of GTK+ before it was split out some time ago. The segfault with kernel oops that I can't get around occurs while glib's configure script is checking for libpthread. Specifically, it links http://beerandrocks.net:8080/~spbecker/oops/conftest.c against libpthread and then runs it. I've somewhat convinced myself this is either a kernel and/or a header problem. It seems I'm only able to reproduce this problem when trying to compile and run that code while running 2.6.12 from cvs. As I previously mentioned, I tested the offending code on a kernel I compiled from a 2.6.10 snapshot some time ago, and it ran with no segfault or oops. -Steve
