7

I am connected with SSH to a machine on which I don't have root access. To install something I uploaded libraries from my machine and put them in the ~/lib directory of the remote host.

Now, for almost any command I run, I get the error below (example is for ls) or a Segmentation fault (core dumped) message.

ls: relocation error: /lib/libpthread.so.0: symbol __getrlimit, version 
GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

The only commands I have been successful running are cd and pwd until now. I can pretty much find files in a directory by using TAB to autocomplete ls, so I can move through directories.

uname -r also returns the Segmentation fault (core dumped) message, so I'm not sure what kernel version I'm using.

Community
  • 1
devil0150
  • 651
  • 3
  • 7
  • 14
  • Side note: to install stuff without root rights in a nice and clean way I recommend the nix package manager (from NixOS). – Daniel Jour May 27 '17 at 16:47

3 Answers3

28

Since you can log in, nothing major is broken; presumably your shell’s startup scripts add ~/lib to LD_LIBRARY_PATH, and that, along with the bad libraries in ~/lib, is what causes the issues you’re seeing.

To fix this, run

unset LD_LIBRARY_PATH

This will allow you to run rm, vim etc. to remove the troublesome libraries and edit your startup scripts if appropriate.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
24

The problem is that you have put a copy of glibc into your ~/lib directory, and that library is incompatible with the system you've uploaded it to. The library is being referenced as ~/lib is specified in $LD_LIBRARY_PATH.

To temporarily fix this, simply unset LD_LIBRARY_PATH - this will work as unset is a shell built-in. You will then be able to run your favourite text editor in order to remove whatever it is in your startup files which is setting the variable in the first place.

Philip Kendall
  • 593
  • 3
  • 9
  • 6
    OP has put an _incomplete_ copy of glibc into the `~/lib` directory. All of the shared libraries provided by the "glibc" source tree must be installed and upgraded in lockstep. The catch is, that list includes the dynamic linker itself (often but not always `/lib/ld-linux.so.2`) and LD_LIBRARY_PATH cannot override the location of the dynamic linker. So it's not possible to install a newer (or older) copy of glibc and select it with LD_LIBRARY_PATH. You can only install in an alternate location (don't use /usr/local/lib!) and then recompile stuff against it. – zwol May 28 '17 at 18:19
0

What I have found on linux Yocto Sumo v4.14, but should be identical to all linux kernels:

  • You can swap between 2 versions of major libraries, in /lib the default one and /usr/lib the user post installed, or post appended one.
  • For that simply set the LD_LIBRARY_PATH variable on every command. Or alternatively call export from the start i.e.
export LD_LIBRARY_PATH=/lib
# now everything should work again since there should 
be a valid backup version of glibc in /lib

# try use a command again 
ls ./

#if this works you can overwrite the broken version of glibc in /usr/lib
cp -faL /lib/libc.so* /usr/lib/
cp -faL /lib/libc-*so* /usr/lib/

#should be optional but for the sake of completeness, as the libc package 
# installs all of the following: 
# direct dependencies and are versioned using 
# the same version number as glibc
cp -faL /lib/ld*.so* /usr/lib/
cp -faL /lib/libdl*.so* /usr/lib/
cp -faL /lib/libm*.so* /usr/lib/
cp -faL /lib/libnsl*.so* /usr/lib/
cp -faL /lib/libnss*.so* /usr/lib/
cp -faL /lib/librt*.so* /usr/lib/
cp -faL /lib/libutil*.so* /usr/lib/
cp -faL /lib/libpthread*.so* /usr/lib/
cp -faL /lib/libcrypt*.so* /usr/lib/
cp -faL /lib/libresolv*.so* /usr/lib/

This should do the trick !

rsacchettini
  • 1
  • 1