Penguin
Note: You are viewing an old revision of this page. View the current version.

error while loading shared library. cannot open shared object file

This occurs when it can't load a shared library, 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 shared library is not in /usr/lib. Either moving the existing library to /usr/lib, or creating a symlink in /usr/lib to its current location (e.g., ln -s /usr/local/lib/libdmalloc.so /usr/lib/libdmalloc.so).


"No such file or directory" or "Bad interpreter: no such file or directory"

If you see this message when trying to run a program, even though you can plainly see it right in front of you, there are a couple of possibilities:

;1) Executable is a script:

If it is some kind of script, it might point to an interpreter that doesn't exist on your system. For example, it used to be common to see perl scripts whose first line was
  1. /usr/local/bin/perl

But if you had perl installed as /bin/perl or /usr/bin/perl you would get this message.

Another possibility is that the script was edited on windows, or another editor that added windows' style line endings (carriage-return + linefeed). Try using "dos2unix" or "tr -d '\r'" to go back to normal newline (linefeed only) line endings.

;2) Executable is a binary: Your dynamic binary executable is linked against a library that doesn't exist, or against a specific dynamic library on your system that has the same name (but different binary interfaces??) as 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!

Sometimes, missing libraries can cause ldd itself to fail, which can make it difficult to determine what the problem is. 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/ld-linux.so.2 --verify --list ./ninfo /usr/local/bin/ninfo: error while loading shared libraries: libc.so.5: cannot

open shared object file: No such file or directory

or

$ strings ./ninfo | grep '\.so' /lib/ld-linux.so.1 libtermcap.so.2 libc.so.5

and it 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?)


Xlib: connection to ":0.0" refused by server

Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server some_app: unable to open display ":0.0"

The user running the command is different to the user that started the X-server, or is otherwise not allowed by the X server to create new (graphical) windows.

Also see the XFree86Notes page on giving other users permission to open graphical windows on your X server.


-bash: /bin/bash: Permission denied: /path/to/program

bash: /path/to/script: /bin/bash: bad interpreter: Permission denied

Note that other shells (such as zsh(1)) don't give the "bad interpreter" part of the message for some of the following circumstances - only bash(1) seems to.

Possible causes for this message (in decreasing order of probability):

  • /bin/bash exists and runs fine; the probable cause is the program is a script and the "u+x" bit is not set on the script. ("chmod a+x program" would also set it.) Bash will report this even if the script is not a bash script - that is because bash has to first load and run the script, which is can't do.
  • This error occurred on my system on the /var directory because /dev/hda5 was mounted on /var with the option "noexec". This is also the case for CDROMs and floppy drives - by default in many distributions you can't run executables from removable media. (This is caused by the "user" mount option.)
  • It is possible (but very unlikely) that /bin/bash (or whatever shell the script uses) isn't executable, and since it is a bash script the kernel is trying to start bash.

chmod a+rx /bin/bash /usr/bin/perl /usr/local/bin/perl /path/to/your/script/here

this will mark these all as executable and readable by everyone.

  • It is possible that the interpreter being used is not runable, for example it has unresolved link dependencies as described earlier in the page.
  • I got errors similar to this when my locale files were generated incorrectly (I was using Debian at the time). Originally I thought I had suffered filesystem corruption, as the output of ls(1) was rubbish, and no text scripts would run, although binaries were fine. Specifically, the LC_CTYPE environment variable was defaulting to en_US.UTF-8 but locale-gen(8) had somehow generated the wrong encoding. Anyway, doing LC_ALL=C ; export LC_ALL

changed it back to using ascii(7) characters, and my scripts ran again.

  • Mandrake 9.1 using the secure kernel: this error occurs when the directory containing the script is world writable. e.g.: the script /!MyDir?/myscript.sh will give this error if the directory /!MyDir? is world- (or group-?)writable. chmod 700 /!MyDir? and try again :)

ping: unknown protocol icmp

cobalt root # ping ping: unknown protocol icmp.

I googled for this, and only found suggestions to make sure /proc was mounted (which it was) and that my interfaces were correctly configured (which they were, and I dont see why this would matter). I asked GreigMcGill, and he suggested /etc/protocols issues: my /etc/protocols was fine, BUT my system had taken upon itself to declare my LDAP server as authoritative for protocols in /etc/nsswitch.conf
protocols: ldap [NOTFOUND=return? files

Deleting the ldap portion (as I don't have protocols info in the LDAP tree) fixed

protocols: files.

ping: sendto: Operation not permitted

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

The interface you are pinging out of (192.168.66.10) is firewalled. Fix your firewall :)


Your shell hangs

Your shell hangs, and it even ignores ctrl-c. You have to close the xterm (or gnome-terminal or konsole) to remove the process.

Possible answer: you have inadvertently typed the special "stop" flow control character used by terminals. By default, this is ^S (control-s). By default, control-q sends a start character again. 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.

$ stty stop ""

will mean that no character sends a stop character.

$ stty stop " "

causes your terminal to stop every time you press space. This is probably not a very clever thing to do (unless you are playing a trick on someone...)

Re-defining the stop key has the added advantage that you can then use ctrl-s to search your command line in bash(1)/zsh(1) as well as ctrl-r for reverse search.


Xscreensaver gives "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 binary drivers for XFree86. The problem is that these drivers mmap(2) large parts of the graphics card's memory and registers into virtual memory, and xscreensaver defaults to having a limit on the amount of memory it uses. For example
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 ${HOME}/.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 $HOME/.xsession-errors file.

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


For more errors see: CategoryErrors