How to Recover After Deleting the Symbolic Link Libc.So.6

How to recover after deleting the symbolic link libc.so.6?

You could simply run ldconfig. Most distributions ship this as a static binary.

How to recover after replacing the symbolic link libc.so.6 with another updated libc.so.6?

If you have already fallen into such issue without any preparation, well, it's already great chances you can't restore without external rescue boot. For future experiments, you can use one of the following preparations:

• Start mc (Midnight Commander) or another complex shell-like tool with embedded filesystem actions implementation, in a separate terminal.
• Create "rescue" tool set (like one in FreeBSD under /rescue).
• Start a REPL tool of any script language (Python, Ruby, etc.); maybe some imports (like sys, os, os.path in Python) shall be called before a dangerous step.

(For all such actions, backup copy of critical system paths before experiments is a good manner.)

But some minor actions can be done in a bare shell without working libc. In most interactive shells like bash, there are some useful builtins, so you can:

• echo *, echo /lib/* instead of ls
• echo -n >$file to make it empty; for ldconfig, this effectively removes it from libraries because ldconfig lists only correctly recognized libraries in its cache;
• if printf is shell builtin (as for modern bash), you can create any binary using it and shell redirection; this is very slowly and typo prone but still can be a chance.

Next, setting LD_PRELOAD for a proper libc version before each external command invocation allows replacing any library with another one; e.g. LD_PRELOAD=/lib/libc-2.11.3.so ls will run ls with all external symbols found in /lib/libc-2.11.3.so have overridden their namesakes from the one you have installed. (Don't try use env before export specification! It will fail with broken libc and isn't needed for any B-group shell like bash.) Exporting LD_LIBRARY_PATH with a backup copy of /lib, /usr/lib allows to get out from most problems with broken main library directories. (NB this method was described in the question you linked to. Did you really try it?)

I hope another hacker methods can be added to this list.

P.S. Shouldn't this question be moved to ServerFault?

Fixing libc.so.6 unexpected reloc type 0x25

my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64

See this answer for explanation of why this can't work.

Is there any way I can fix this so that I can get gcc4.9 up and running on this system?

Your best bet is to install whatever GCC package comes with the SuSE system, then use that GCC to configure and install gcc-4.9 on it.

If for some reason you can't do that, this answer has some of the ways in which you can build gcc-4.9 on a newer system and have it still work on an older one.

is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?

Contrary to popular belief, fully-static binaries are generally less portable then dynamic ones on Linux.

gdb core dump can not see any symbols after sudo apt-get install libc6-dbg

I get all the thing wrong , showing in the below:

What probably happened is that apt-get install libc6-dbg also updated already installed libc6, and the currently installed libc.so.6 no longer matches the one that was used when the core file was generated.

For GDB analysis, you need an exact matching copy as what was used at runtime.

So you'll need to re-install the old version of libc6 (look in /var/log/apt/history.log to find out what it was), and a matching version of libc6-dbg.

Update:

It seems that the command apt-get install libc6-dbg get the libraries with version 2.15-0ubuntu10.12

Just as I guessed could be the case.

How can I recover it to the version in 2.15-0ubuntu10.4

This is really a sysadmin question, but here is an answer I found on Google ;-)

sudo apt-get install libc6=2.15-0ubuntu10.4 libc6-dbg=2.15-0ubuntu10.4

should do the trick.

How can I look inside a Linux .so or .a object and see what functions they contain?

you can do nm Linux.so and it'll show the functions and variables inside the .so file.

usr/bin/ld: cannot find -l nameOfTheLibrary

If your library name is say libxyz.so and it is located on path say:

/home/user/myDir

then to link it to your program:

g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog

Multiple glibc libraries on a single host

It is very possible to have multiple versions of glibc on the same system (we do that every day).

However, you need to know that glibc consists of many pieces (200+ shared libraries) which all must match. One of the pieces is ld-linux.so.2, and it must match libc.so.6, or you'll see the errors you are seeing.

The absolute path to ld-linux.so.2 is hard-coded into the executable at link time, and can not be easily changed after the link is done (Update: can be done with patchelf; see this answer below).

To build an executable that will work with the new glibc, do this:

g++ main.o -o myapp ... \
   -Wl,--rpath=/path/to/newglibc \
   -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2

The -rpath linker option will make the runtime loader search for libraries in /path/to/newglibc (so you wouldn't have to set LD_LIBRARY_PATH before running it), and the -dynamic-linker option will "bake" path to correct ld-linux.so.2 into the application.

If you can't relink the myapp application (e.g. because it is a third-party binary), not all is lost, but it gets trickier. One solution is to set a proper chroot environment for it. Another possibility is to use rtldi and a binary editor. Update: or you can use patchelf.

---

Related Topics