A while back, while working on a project that was emulating a filesystem layer in userspace, I found out (the hard way) that the glibc implementation of the dynamic loader, ld.so, uses inodes to uniquely identify libraries. That is to say, when asked to load a shared library, it checks the inode of the file first to see if it's already been loaded.

I, of course, had stubbed out the inode-fetching portion of the filesystem API -- making it return inode 1 for everything -- and so could not figure out why ld.so was failing to load the second dynamically-loaded library that a program requested.

I feel rather slow, but it was not until today -- working on a totally different project that nonetheless still deals with the inner workings of ld.so, about a year later -- that I realized a simple truth: this is how ld.so handles symlinked libraries. That is to say, if you have a library libfoo.so.5 that is a symlink to libfoo.so.5.1, and you have the following scenario:

Then ld.so can resolve the same-ness of libfoo.so.5 and libfoo.so.5.2 immediately without any fuss at all, simply by checking the inode -- after all, if you follow the symlinks, you'll get the same inode.

Quite clever, I think, and I'm mad at myself for not realizing this.

- ethereal