Steve, I don't see a kernel oops. I checked /var/log/messages, and a few others. I have verified that klogd and syslogd are running. Bryan -----Original Message----- From: Stephen P. Becker [mailto:geoman@xxxxxxxxxx] Sent: Thursday, June 30, 2005 3:09 PM To: Bryan Althouse Cc: 'Linux/MIPS Development' Subject: Re: Seg fault when compiled with -mabi=64 and -lpthread Bryan Althouse wrote: > I have a problem when linking a 64 bit application with libpthread. I > appears to link fine, but it will seg fault when I execute it. I wrote > an empty C program called empty.c: > > > > int main (void) > > { > > return 0; > > } > > > > I cross compile it with: > > /opt/redhat/mips64linux-031001/H-i686-pc-linux-gnulibc2.2/bin/mips64-linux-g nu-gcc > -mabi=64 empty.c -o empty -lpthread > > The executable will seg fault. If I remove the -lpthread, it is fine. > Also, if I change the 64 to 32, it is fine. > > > > Maybe I have a bad libpthread in /lib64? If I type "file > /lib64/libpthread-0.10.so" I get: "ELF 64-bit MSB shared object, mips-3 > MIPS R3000_BE, version 1, not stripped". Looks fine to me. Should I > cross compile and replace libpthread? If so, where can I find the source? > Wow, so I'm not just smoking crack. I ran into essentially the same exact problem with my n32 userland while trying to build glib (not glibc). The configure script kept dying while trying to determine if libpthread was available. Looking at the config.log, I noticed that the conftest code was causing a segfault. Furthermore, this causes a kernel oops (you should check your kernel logs for an oops). I isolated the conftest code, and it is available at: http://beerandrocks.net:8080/~spbecker/oops/ In that directory is also a statically linked big endian n32 executable, as well as dumps of oops messages that I was able to reproduce 100% of the time on both ip32 and ip22 systems. If anyone is in an experimenting mood, try to run that executable on a mips64 box (with n32 binary support enabled obviously) and see what happens. The interesting thing about this problem is that it only happens with recent kernels. I can't speak for 2.6.11 since I haven't tested it yet, but the oops only occurred while running 2.6.12 from cvs HEAD. When running my 2.6.10 build that has been on my indy for some time, the conftest code runs fine without any segfault, and there is no kernel oops. -Steve
