These are not necessarily duplicates, and probably are not duplicates. Libraries are present for those versions, but versions are not truly determined in libraries via file name; file name should match version, but that’s for human and practical purposes. Consider also that some of those might be symbolic links.
First, use “ls -l <filename>” on those. It is likely that libnvjpeg.so points to libnvjpeg.so.12. There might be something libnvjpeg.so.12 points to in some cases. This makes it possible to search for a “default” version, or a “most recent within the major release 12” (for this case). There might be different patch levels, and I’m making this up for actual versions, but imagine there is a libnvjpeg.so.12.1 and a libnvjpeg.so.12.2. This would mean you could have two minor releases simultaneously. Why would you do that? Well, perhaps a bug fix broke something, but only for some applications. You could install both versions. The granularity might include:
- “default” version, no numbering, pointing to a major release number, e.g.,
name.so -> name.so.12.
- “major” version can point to a minor version, e.g.,
name.so.12 -> name.so.12.1.
- “minor” version can point to patch level, e.g.,
name.so.12.1 -> name.so.12.1.5.
- Versioning can go to many levels, e.g., in a developer’s testing, maybe there is
name.so.12.1.5.4.5.6.
The above uses file names, which you might consider some “Jedi trickery” to use files and packages to manage what is there. Internally, libraries also have versions. Check this command (using one of your example files):
cd /usr/local/cuda/targets/aarch64-linux/lib/
objdump -p libnvjpeg.so | grep 'SONAME'
The SONAME is how the linker itself determines versions. Filenames are pretty much ignored internally. Note that if you have some finely grained release version, e.g., something like libsomething.so.1.2.3, that the application itself will care only about the major release in the SONAME. If the application just wants the most recent of a given major release, then this simplifies life for the application needing a library.
Your library files are not duplicates unless they are all the same patch version down to the tiniest level, and all have the same SONAME. It is true that it is unusual to have multiple patch releases among libraries which have the same major version since most of the time only the most recent patch is used, but it isn’t necessarily an error to have multiple versions if something requires those different patch releases.
Getting back to the original question or problem, any program which needs a library really needs one which the linker presents which has the correct SONAME. Those libraries with libnvjpeg presented via the ldconfig -p command are those which are found automatically. If there is no compatible SONAME, then you need to add the library with the correct SONAME. Normally this means the actual file with the version in it, but also pointed at via a symbolic link with a more generic name.
Let’s pretend though that you have this (which you do actually have, this is from your ldconfig -p):
||libnvjpeg.so.12 (libc6,AArch64) => /usr/local/cuda/targets/aarch64-linux/lib/libnvjpeg.so.12|
|---|---|
||libnvjpeg.so (libc6,AArch64) => /usr/local/cuda/targets/aarch64-linux/lib/libnvjpeg.so|
||libnvjpeg.so (libc6,AArch64) => /usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so|
You have a version in “/usr/local/cuda/targets/aarch64-linux/lib/”, and another version in “/usr/lib/”. Do they both have the same SONAME? If they differ, then you can use both versions. It would be up to the application. When compiling, if a different version is needed, then you might have to adjust your build spec to use the other one.
A question then becomes “how was the library installed?”. Files in “/usr/local” tend to be installed with a package. You won’t find a package for any symbolic link, so make sure when you do the following you name actual files, but look at this particular file and find the package it belongs to:
# Must name the full path to the hard linked file:
dpkg -S /usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so
You will find the /usr/local/ versions don’t have a package owning them (most of the time). Which version does your program want? You might be able to do either of:
- Install the version required.
- Change the link spec if the wrong one is found first, but the right one is present.
If you are interested in more details, check this out:
