error while loading shared library. cannot open shared object file

Use ldd(1) to determine which libraries this program is trying to link against and which ones are missing or can't be linked against, eg. ldd /bin/cat.

In Linux, one possible reason for this is that the SharedLibrary is not in /usr/lib or one of the other directories which are searched for shared libraries. In that case, add the directory to /etc/ and run ldconfig(8). (Other ways of dealing with this are creating a SymLink in /usr/lib to the current location of a library or moving the library to /usr/lib (this is not advisable).)

/path/to/program: No such file or directory
/path/to/program: bad interpreter: No such file or directory

  • If it is a dynamic BinaryExecutable, it is possibly linked against a library that doesn't exist, or against a specific SharedLibrary on your system that has the same name but contains different symbols as on the machine that the file was compiled on.

    This is particularly annoying as you can also get this message when trying to use ldd(1) to find out which dynamic library is causing the problem. Eg.:'''

    $ ./ninfo
    zsh: no such file or directory: ./ninfo
    $ file ninfo
    ninfo: ELF 32-bit LSB executable, Intel 80386, version 1,
     dynamically linked (uses shared libs), not stripped
    $ ldd ./ninfo
    /usr/bin/ldd: ./ninfo: No such file or directory

    This makes diagnosis a bit harder! However, you can try:

    $ /lib/ --verify --list ./ninfo
    /usr/local/bin/ninfo: error while loading shared libraries: cannot open shared object file: No such file or directory


    $ strings ./ninfo | grep \.so

    It then becomes clear that this program is linked against very old versions of libraries that don't exist any more. The program needs to be re-compiled against current versions. (You do have the source code, right?)

  • If the executable is some kind of script, it might point to an interpreter that doesn't exist on your system. For example, Perl scripts often started with #!/usr/local/bin/perl when you had perl installed as /bin/perl or /usr/bin/perl.

    Another possibility is that the script was edited on MicrosoftWindows, or another editor that added Windows style line endings (Carriage Return + Linefeed). Try using dos2unix or tr -d '\r' to go back to Unix style line endings (Linefeed only).

    Lastly, the script might be fine and its interpreter might exist, but the interpreter might not be launchable. This is what bad interpreter means here, but only bash(1) seems to provide that helpful part of the message, not zsh(1). If that is the case, see below.

/path/to/program: Permission denied
/path/to/program: bad interpreter: Permission denied

  • The executable bit is not set on the program file. Issue chmod a+x /path/to/program to fix this.
  • The program is located on a Partition that is mounted noexec. Alternatively, on many LinuxDistributions you can't run executables from removable media such as CDROMs and floppies, due to the user mount option. Check your /etc/fstab. See also mount(8).
  • Some secure Kernels used by certain LinuxDistributions will throw this error occurs when the directory containing the program is world writable, eg. if you are trying to launch ~/bin/prog and ~/bin is world/group-writable. Issue chmod go-w ~/bin and try again.
  • If you get the bad interpreter message, the program is a script whose interpreter has one of the above problems. Unfortunately, only bash(1) seems to provide that helpful part of the message. If you use another shell, such as zsh(1), you must check both the script and its interpreter for these problems.

Xlib: connection to ":0.0" refused by server

The user running the command is different to the user that started the XServer, or is otherwise not allowed by the XServer to create new (graphical) windows. See XFree86Notes on giving other users permission to open graphical windows on your XServer.

ping: unknown protocol icmp

If /proc is mounted, your interfaces are correctly configured, and /etc/protocols is fine, check /etc/nsswitch.conf. It might be declaring other sources than /etc/protocols as authoritative:

protocols: ldap [NOTFOUND=return] files

Here you could allow /etc/protocols as a fallback:

protocols: ldap files

Or delete every other source all together:

protocols: files

ping: sendto: Operation not permitted

PING ( 56 data bytes
ping: sendto: Operation not permitted
ping: wrote 64 chars, ret=-1

The interface you are pinging out of ( is firewalled. Fix your FireWall.

The shell hangs

Your shell hangs and even ignores Ctrl-C. You have to close the terminal to remove the process.

Possible answer: you have inadvertently typed the special stop flow control character used by terminals. By default, this is Ctrl-S, with Ctrl-Q sending a start character. This is particularly common if you were pressing Ctrl-D or Ctrl-A or a nearby key on a QWERTY keyboard.

You can use the stty(1) program to change this behaviour. stty -ixon will tell your terminal not to use XON/XOFF flow control. You could also say stty stop '' to specify that no character sends a stop character. If you want to play a practical joke on someone you could issue stty stop ' ', which will tell the terminal to stop every time they hit space. To restore the default, you can use stty stop ^s (the circumflex is a common way to spell “Ctrl-” on Unix). Redefining the stop key has the added advantage that you can then use Ctrl-S to search your command history in bash(1)/zsh(1) as well as Ctrl-R for reverse search.

Xscreensaver: couldn't create GL context for visual 0x21

Symptom: xscreensaver(1) gives this message when trying to run one of the 3D screensavers, even though you can run it fine from the command line (such as $/usr/lib/xscreensaver/bubble3d). Or perhaps it works fine when run in a window, but not fullscreen.

You are probably using the nVidia BinaryDrivers for XFree86. The problem is that these drivers mmap(2) large parts of the graphics card's memory and registers into VirtualMemory, and xscreensaver(1) defaults to having a limit on the amount of memory it uses. Eg.
20502 john      16  10  139m 8096 2632 S  1.9  3.2   0:00.22 sierpinski3d

This OpenGL application has 139MB of addressable space in use, but it is not using that much virtual memory. Edit ~/.xscreensaver and edit the line that says

memoryLimit:    50M

to either something much bigger, or set it to 0 (for no limit).

*** attempt to put segment in horiz list twice

You might see this error message if you use GNOME – it appears quite regularly in my ~/.xsession-errors file.

It is "mostly harmless," seems to occur most frequently when activating menus, and appears to be caused by libsvg/libarts. It implies a minor problem with one of the SVG icons.

For more errors see: CategoryErrors