Re: corrupted ld.so

Michael L. Galbraith (mikeg@weiden.de)
Sat, 21 Mar 1998 09:10:51 +0100 (MET)


On Sat, 21 Mar 1998, Chris Atenasio wrote:

> Just a warning note to users out there:
>
> About two hours ago I recompiled ld.so 1.9.5 with gcc 2.8.1. Big mistake.
> The thing wouldnt even compile until I turned off all optimizations
> ("boot1.c:897: fixed or forbidden register was spilled.) So anyway once I
> finaly did compile and install it, everything starts coredumping and linux
> wont boot anymore. Turns it's corrupted for the most part and completely
> inoperative. Too bad i forgot to back up the old one (notice I said
> "two hours ago" heh.) Anyways either my system has issues or gcc 2.8.1
> does. I remember reading somewhere that turning off optimizations messes
> up asm if you dont explicitly specify -fasm.(corrections?) Maybe that was
> the problem...
>

Oooo.. shouldn't have done any of that :) Snag 1.9.7.. works well. I just
compiled it with a gcc-2.8.1 glibc->libc5 cross-compiler in order to solve a
frustrating problem with shared libraries on my (glibc-2.0.7-pre4) system.

This is off topic, but may save some other folks heart-ache and core dumps.

/usr/local/src/gnu/glibc/glibc-2.0.7-pre4/elf/ldd /usr/local/bin/netscape
libXt.so.6 => /usr/X11/lib/libXt.so.6 (0x40005000)
libSM.so.6 => /usr/X11/lib/libSM.so.6 (0x4004b000)
libICE.so.6 => /usr/X11/lib/libICE.so.6 (0x40054000)
libXmu.so.6 => /usr/X11/lib/libXmu.so.6 (0x4006d000)
libXpm.so.4 => /usr/X11/lib/libXpm.so.4 (0x4007e000)
libXext.so.6 => /usr/X11/lib/libXext.so.6 (0x4008d000)
libX11.so.6 => /usr/X11/lib/libX11.so.6 (0x40098000)
libdl.so.1 => /lib/libdl.so.1 (0x4013a000)
libc.so.5 => /lib/libc.so.5 (0x4013d000)
libm.so.5 => /lib/libm.so.5 (0x401f9000)
libc.so.6 => /lib/libc.so.6 (0x40202000)
/lib/ld-linux.so.1 => /lib/ld-linux.so.2 (0x2aaaa000)

/usr/local/src/gnu/glibc/glibc-2.0.6/elf/ldd /usr/local/bin/netscape
libXt.so.6 => /usr/X11/lib/libXt.so.6 (0x40005000)
libSM.so.6 => /usr/X11/lib/libSM.so.6 (0x4004b000)
libICE.so.6 => /usr/X11/lib/libICE.so.6 (0x40054000)
libXmu.so.6 => /usr/X11/lib/libXmu.so.6 (0x4006d000)
libXpm.so.4 => /usr/X11/lib/libXpm.so.4 (0x4007e000)
libXext.so.6 => /usr/X11/lib/libXext.so.6 (0x4008d000)
libX11.so.6 => /usr/X11/lib/libX11.so.6 (0x40098000)
libdl.so.1 => /lib/libdl.so.1 (0x4013a000)
libc.so.5 => /lib/libc.so.5 (0x4013d000)
libm.so.5 => /lib/libm.so.5 (0x401f9000)
libc.so.6 => /lib/libc.so.6 (0x40202000)
/lib/ld-linux.so.1 => /lib/ld-linux.so.2 (0x2aaaa000)

/usr/local/src/system/ld.so-1.9.7/util/ldd /usr/local/bin/netscape
libXt.so.6 => /usr/X11/lib/libc5/libXt.so.6 (0x4000d000)
libSM.so.6 => /usr/X11/lib/libc5/libSM.so.6 (0x4004d000)
libICE.so.6 => /usr/X11/lib/libc5/libICE.so.6 (0x40056000)
libXmu.so.6 => /usr/X11/lib/libc5/libXmu.so.6 (0x4006c000)
libXpm.so.4 => /usr/X11/lib/libc5/libXpm.so.4 (0x4007d000)
libXext.so.6 => /usr/X11/lib/libc5/libXext.so.6 (0x4008a000)
libX11.so.6 => /usr/X11/lib/libc5/libX11.so.6 (0x40094000)
libdl.so.1 => /lib/libc5/libdl.so.1 (0x4012e000)
libc.so.5 => /lib/libc5/libc.so.5 (0x40131000)
libm.so.5 => /lib/libc5/libm.so.5 (0x401ed000)

All versions tested get confused when LD_LIBRARY_PATH is set to what used to
be a correct search path. If a shared lib is encountered in the search path,
the output points to that library regardless of whether the binary is libc5 or
glibc compiled. With no LD_LIBRARY_PATH, ldd-1.9.7 reports correctly.. both
glibc ldd versions tested (glibc-2.0.6 and 2.0.7-pre4) produce incorrect output
whether LD_LIBRARY_PATH is set or not.

Maybe something else is wonkies in my system to account for this, but for me
the correct answer seems to be no LD_LIBRARY_PATH and ld.so-1.9.7.

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu