dlopen definition of "same library"

Question

According to the dlopen(3) man page:

If the same library is loaded again with dlopen(), the same file handle is returned.

What does "same library" mean? Same filename? Same path? Same inode? Same SONAME? Something else? How does this behavior interact with soft links?

Assume I am interested in ELF so's and mainstream Linux distros (Debian / Arch / RHEL families).

Example consequences:

• If "same library" means "same SONAME" then I could have the same file twice with different names be loaded and only get one handle. If "same library" means "same filename" then I would probably get a horrible mess with colliding symbols.
• If symlinks are followed back to the file and "same library" means "same filename", then multiple symlinks to one file are okay, else if the filename of the symlink is used instead, again things are a horrible mess.
• If "same library" means "same path" and two paths exist to a file (e.g. with hardlinks), things are a mess, else if "same library" means "same inode", all is okay.

Answer 1

I decided to dig into the musl source for, well, a possible interpretation of the words. The function in question is load_library(), at https://github.com/ifduyue/musl/blob/3ab2a4e02682df1382955071919d8aa3c3ec40d4/ldso/dynlink.c#L990.

The "already loaded" search for (p=head->next; p; p=p->next) if (...) return p; occurs in two places:

1. First in the non-pathname case, where the name itself is checked for dup againsr a shortname (the shortname is not a soname, rather a basename of the resolved filename like libfoo.so)
2. Then in a general path, where the device and inode numbers are searched for dup. The values come from fstat on an fopen'ed handle.

In addition, the shortname is only saved in a nom-path case.

---

The #2 case seems to explicitly merge hard links. The use of fopen also implicitly merges symlinks.

At no point was the ELF file itself ever consulted for sameness. So it's not a horrible mess, but not super smart either.

---

I am way too tired to read glibc right now, but I can't imagine anything unusual there. Node.js's AIX polyfill uses inode too.