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