Current glibc CVS doesn't work on i386-gnu
Details on the bug that I ran into in December on i386-gnu: (http://sources.redhat.com/ml/libc-alpha/2002-12/msg00202.html) Program received signal EXC_BAD_ACCESS, Could not access memory 0x in ?? () The problem seems to be this line: 73 return __stpnpy (__dst, __src, __len) - __dst; in mach/mach/mig_support.h When I look at elf/ld.so with `readelf -a' the plt section contains: 000168a4 5107 R_386_JUMP_SLOT __stpncpy Should the sym. value really be ? I'm not sure because: 00016884 4307 R_386_JUMP_SLOT __ctype_b_loc 00016898 4b07 R_386_JUMP_SLOT __ctype_toupper_loc But there are no entries like this in the currently installed ld.so and all three of these symbols are new. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Current glibc CVS doesn't work on i386-gnu
> When I look at elf/ld.so with `readelf -a' the plt section contains: > > 000168a4 5107 R_386_JUMP_SLOT __stpncpy My hurd cross-build doesn't have that reference. > Should the sym. value really be ? > > I'm not sure because: > > 00016884 4307 R_386_JUMP_SLOT __ctype_b_loc > 00016898 4b07 R_386_JUMP_SLOT __ctype_toupper_loc > > But there are no entries like this in the currently installed ld.so and > all three of these symbols are new. That indicates the symbol is undefined. Look at the corresponding lines in the readelf -s output. There should be no undefined symbols in ld.so, so this looks like a bug in how it's getting built. -z defs would have caught this, and I've added that to the link for ld.so. We'll have to look into what is breaking the build on the Hurd. Likely wrong objects being brought in or the rtld-* compilations not happening right. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
