After emerging glibc-2.11.2, trying to run anything results in a segfault. The latest usable version of glibc seems to be 2.10.1-r1
Created attachment 250017 [details] output of "emerge --info"
*** Bug 340699 has been marked as a duplicate of this bug. ***
in reality, mips team/users are going to have to debug this. i dont have any real access/interest in mips hardware anymore.
coredump analysis of some crashing application: (gdb) bt #0 0x00000000 in ?? () #1 0x2ab8fdc0 in free () from /usr/lib/libslang.so.2 Backtrace stopped: frame did not save the PC (gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 fffffff8 00000000 00000001 00000000 00000001 00000000 2aee5a70 t0 t1 t2 t3 t4 t5 t6 t7 R8 2aad0b1c ffff9014 81010100 3b3b3b3b 004d5d42 2aac5b14 ffffffff 2add797c s0 s1 s2 s3 s4 s5 s6 s7 R16 00000030 0000000c 2af1a3b8 7ffcc1e0 2af1bdd0 2aef8528 0000000d 00000006 t8 t9 k0 k1 gp sp s8 ra R24 0000027b 00000000 00000000 00000000 2af22960 7ffcc1c0 7ffcc1c0 2ab8fdc0 sr lo hi bad cause pc 0800f013 0002ce2f 00000214 00000000 10800008 00000000 fsr fir 00000000 00000000 (gdb) disassemble 0x2ab8fda0, 0x2ab8fdf0 Dump of assembler code from 0x2ab8fda0 to 0x2ab8fdf0: 0x2ab8fda0 <__ctype_toupper_loc+0>: lw t9,-32752(gp) 0x2ab8fda4 <__ctype_toupper_loc+4>: move t7,ra 0x2ab8fda8 <__ctype_toupper_loc+8>: jalr t9 0x2ab8fdac <__ctype_toupper_loc+12>: li t8,639 0x2ab8fdb0 <free+0>: lw t9,-32752(gp) 0x2ab8fdb4 <free+4>: move t7,ra 0x2ab8fdb8 <free+8>: jalr t9 0x2ab8fdbc <free+12>: li t8,635 0x2ab8fdc0 <__lxstat64+0>: lw t9,-32752(gp) 0x2ab8fdc4 <__lxstat64+4>: move t7,ra 0x2ab8fdc8 <__lxstat64+8>: jalr t9 0x2ab8fdcc <__lxstat64+12>: li t8,632 0x2ab8fdd0 <atan+0>: lw t9,-32752(gp) 0x2ab8fdd4 <atan+4>: move t7,ra 0x2ab8fdd8 <atan+8>: jalr t9 0x2ab8fddc <atan+12>: li t8,629 0x2ab8fde0 <__strtoll_internal+0>: lw t9,-32752(gp) 0x2ab8fde4 <__strtoll_internal+4>: move t7,ra 0x2ab8fde8 <__strtoll_internal+8>: jalr t9 0x2ab8fdec <__strtoll_internal+12>: li t8,628 End of assembler dump. I don't have much experience with mips yet, but this looks like .plt section. The other segfault cases look very similar (some function call via null pointer). Right now my guess (still to be confirmed) is that it might be related to the following bug or something like this: http://blog.gmane.org/gmane.comp.lib.glibc.ports/month=20100601
(In reply to comment #3) > in reality, mips team/users are going to have to debug this. i dont have any > real access/interest in mips hardware anymore. Don't worry about this, I guess we will survive somehow :) I just wonder whether somebody has enough privileges and is interested in adding or removing mips/~mips keywords based on the overall shape of certain libraries/applications.
~mips was added to this version because someone else tested it and found it to work for them. reverting that would cause systems to attempt a downgrade and fail thus shifting the "die" from one set of users to another. although i guess the set of user which include you suffer from worse problems. it's easy to drop in custom patches to test. simply place them in /etc/portage/patches/sys-libs/glibc/ and the ebuild should apply them for you.
Yeah, 2.11.2 is working fine on some mips, such as little endian mips64el with n32 ABI. Though I'm running a version with gentoo patchset 1, not 3 or 4 like current in-tree versions. I should make sure latest patchset works soon, but I suspect this has something to do with big endian? mips currently doesn't have a stable tree, so no "mips" keywords, only "~mips". Hopefully we can start having a stable tree once again after ~mips is back in shape. Related to which, we are interested in keywording work, but lots to catch up on too.
Initially I also suffered from this on my Cobalt Qube2. After reinstalling and re-emerging for a second time I got this.... /var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/build-default-mipsel-unknown-linux-gnu-nptl/sunrpc/rpcgen: symbol lookup error: /var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/build-default-mipsel-unknown-linux-gnu-nptl/dlfcn/libdl.so.2: undefined symbol: GLIBC_PRIVATE, version GLIBC_PRIVATE make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/build-default-mipsel-unknown-linux-gnu-nptl/sunrpc/xbootparam_prot.stmp] Error 127 make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/glibc-2.11.2/sunrpc' make[1]: *** [sunrpc/others] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.11.2-r3/work/glibc-2.11.2' make: *** [all] Error 2 * ERROR: sys-libs/glibc-2.11.2-r3 failed: * make for default failed * I'm moving from glibc-2.6 given the stage3 tarball is 2008.0. I'll try glibc-2.10 now and see if that works.
Oh, noticed that 2.12.1 is in tree so just tried that and got this... checking for assembler gnu_indirect_function symbol type support... no checking whether .text pseudo-op must be used... yes checking for assembler global-symbol directive... .globl checking for assembler .type directive prefix... @ checking sysdep dirs... configure: error: The mipsel is not supported. And glibc configure fails. Has glibc lost mipsel support ?
No, they just haven't made a glibc-ports tarball.
(In reply to comment #6) > ~mips was added to this version because someone else tested it and found it to > work for them. reverting that would cause systems to attempt a downgrade and > fail thus shifting the "die" from one set of users to another. although i > guess the set of user which include you suffer from worse problems. Can we add ~mips back to the 2.10.1-r1 ebuild, then I can just mask 2.11 locally for now ? Otherwise I end up going back to 2.9.
(In reply to comment #11) > (In reply to comment #6) > > ~mips was added to this version because someone else tested it and found it to > > work for them. reverting that would cause systems to attempt a downgrade and > > fail thus shifting the "die" from one set of users to another. although i > > guess the set of user which include you suffer from worse problems. > > Can we add ~mips back to the 2.10.1-r1 ebuild, then I can just mask 2.11 > locally for now ? > > Otherwise I end up going back to 2.9. Alternatively, just drop a recent git version of glibc-ports into glibc. I built a working 2.12.2 for le mips32 this way.
Can you guys try 2.13? It works for me.
The issue is not reproducible with glibc-2.13-r2 now (mips32r2, big endian, o32 abi)
OK, I'll mark as fixed. If anyone else is able to reproduce, please reopen.
