So I recently said that i wanted to tackle the problem of QA warnings about missing sonames (Shared Object Names) and to do so I needed to give you some details about shared objects … I’ll add that you probably want to read my explanation about sonames that I wrote last October, since it covers some basis I’d rather avoid repeating here.
The sonames are, as I said before, the names that the dynamic linker will search for when loading a program, or another library, linked to the former. This is because the value of the DT_SONAME tag will be copied into the DT_NEEDED entry for the linked programs; this is why the soname is particularly important. Especially if it’s properly used with ABI-versioning so that libfoo.so.0 and libfoo.so.1 are used for two different, incompatible ABIs that cannot be used interchangeably.
At this point is clear that the soname main importance is to generate proper NEEDED entries; so what happens when it’s missing? In that case, the basename of the library file (which usually is just libfoo.so) is used as NEEDED; since -lfoo will translate to searching libfoo.so without further extension, even when the library is providing (manually) the version numbers, they won’t be encoded into the NEEDED entry at all, and that is, as you might guess, bad.
But is it, always?
While for a general-purpose library (I don’t mean just a library like glib, but rather a library in the broader sense, counting in also specific libraries like libpng or libcurl) the lack of a soname is always a bad thing, there are a few situations where it’s not too important, and can easily be ignored, to avoid spending time where it’s not useful: whenever ABI versioning is not important. This assertion gets then split into further cases, as I’ll try to explain now.
The first case is when you won’t be listing the library as NEEDED ever; this is the case for almost all cases of plugins I know of. They get loaded through dlopen() rather than by the implicit handling of the dynamic linker. This makes sonames and needed entries totally pointless. In these cases, it shouldn’t be a problem even if the library lacks a soname.
The second case relates to internal shared libraries, that might or might not be worth it, as I wrote before. Internal libraries are shipped with the binaries that links to them. They are rebuilt whenever the package is rebuilt. They are only there to reduce the code duplication between binaries. In these cases, sonames, and shared object versioning, are of no use. While it won’t cause trouble to have them, they won’t be necessary.
So, how perfect is the Gentoo QA test? Quite a bit. It won’t cause you to waste time with most of the plugins and most of the internal libraries; on the other hand, there will be false negatives: currently, it only takes the files corresponding to the glob {,usr/}lib*/lib*.so* … this is correct, most of the time, but not always. If the package will add configuration scripts to link to libraries in other paths if the package will install new paths into ld.so.conf, so adding more paths to the default search, where NEEDED entries would be required. These are unfortunately cases it’s not trivial to look out for.
So what about the private libraries that are installed into the /usr/lib path (or similar) for which no soname is required but the warning is printed out? Well you have different ways to proceed: you might just add the soname, which might be more work than it’s worth; you might move the library in a sub-directory and then use rpath to add it to the search path just of the package’s binaries; or you might just use the QA_SONAME_${ARCH} variable to ignore the warning (although I would argue that this should be then reported as a workaround warning by repoman).
My favourite solution here would be to actually use rpath to move the library out of the generic linker search path. While this adds one further search for all the libraries those binaries link to, it reduces the size of the main search path’s content… and you should know that the amount of files in a directory relates to the slowness of accessing the directory itself. While I don’t have any benchmark at hand, I find that much, much easier to deal with (and it’s actually one of the reasons why I’d like for the .la files to disappear: they artificially increase the size of the library paths without good reason, in my opinion).
But if you want to bring upstream the issue, it might be a good time to ask whether those libraries are worth it or not, following the indications I wrote in the article linked at the top of this post.