How does the linker or loader deal with broken soft links for shared libraries?

I have the same shared library in three different paths in the system. Let's say the paths are PATH1, PATH2 & PATH3.

Shared library name is libmylib.so

Now, in PATH1 if I replace the libmylib.so with a broken soft link, it goes and searches in PATH2 for the library.

But, in PATH1 if I replace libmylib.so with some other text file (or some unrelated file) which has the name libmylib.so, then application execution fails stating "not an ELF Header"

I am a little confused by the behaviour? Why does it search the other paths incase of a b开发者_运维技巧roken soft link and fails in case of an incorrect file. I was expecting it to search other paths for incorrect file also.

---

It probably just try to open it. Dangling symbolic link or not present, it will returns the same error. You'd need to do test explicitly for symbolic link if you wanted to do something different. Few programs care.

---

It just does. I don't know of any design document describing the reason for this behavior, but I think this is it: a broken soft link is almost the same as "file not found" and therefore not serious enough to not deserve a workaround. A corrupted library indicates a more serious problem (disk corruption, a file having been overwritten) so it deserves an error message.

Once you decide to display an error message, you must also terminate the program. Otherwise the error message is effectively prepended to what the program writes to stderr; this may be parsed by a second program through a pipe, which then may fail, or propagate the error further until it ends up in a log file which isn't read until months later.

---

with some other text file (or some unrelated file) which has the name libmylib.so

this file is not a broken soft link, this is just a regular file (such as shared object file should be) symbolic link is a special filesystem element (like directory), VFS knows it's nature because of information stored in corresponding inode, but not because of file content.

summary:

• broken symlink is still symlink
• real file with extension .so is treated as shared object (in this case - broken)

check out their attributes (d,-,l):

drwxr-xr-x   2 Ibadinov  staff   68 18 aoû 15:21 dir
-rw-r--r--   1 Ibadinov  staff    0 18 aoû 15:21 file
lrwxr-xr-x   1 Ibadinov  staff    4 18 aoû 15:22 link -> file

basic info:

http://en.wikipedia.org/wiki/Inode

http://en.wikipedia.org/wiki/Symbolic_link#Storage_of_symbolic_links