On Fri, 1 Jul 2005, Stephen P. Becker wrote: > 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. And libpthread is part of glibc, not glib. So if an autoconf test (which I'm assuming is AC_CHECK_LIB() rather than a hand-crafted hack) breaks on running a program linked against libpthread, then it's not a problem with glib, but probably with either glibc or the toolchain used. > 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. If you get an Oops when running software as non-root, then it's a kernel bug, no matter what. Maciej
