On Fri, Jan 26, 2001 at 05:40:07PM -0800, Justin Carlson wrote: > Also, I've run into a problem with ld.so from glibc-2.2 on mips32-linux. > After some hunting, I found that the templates in elf32bsmip.sh for gnu > ld have recently changed to support SHLIB_TEXT_START_ADDR as a (non-zero) > base address for shared library loading. SHLIB_TEXT_START_ADDR defaults > to 0x5ffe0000 in the current sources. For obscure reasons which probably spell IRIX 5.x ELF compatibility ELF shared objects except the dynamic linker itself are linked to this base address. > I'm curious if anyone knows the rationale for these changes. Best conjecture > I've heard is that it allows ld.so to not have to relocate itself, as it will > load by default to the high address. By default ld.so get loaded to 0xfb60000. Again this is an obscure IRIXism. > However, ld.so seems to know nothing about relocating shared library with a > non-zero shared library base address, which causes dynamically linked stuff > to crash spectacularly. > > I think fixing ld.so won't be too difficult, but I'm really wanting to > find out why these changes were made. And whether I'm reinventing some > wheels by fixing ld.so to cope with the new binutils stuff. Glibc 2.0 as of '96 already does this just as glibc 2.2 is supposed to. You may look at the source in the srpm package of glibc 2.1.95 on oss which definately handles this right. Ralf
