Looking at https://askubuntu.com/a/207750/23678 how did the author know which dependency was missing? Is there a generic way to look up the list of dependencies of an executables and which ones are missing?
UPDATE: I just noticed that noticed that https://stackoverflow.com/a/9082947/14731 used
readelf -l [executable]
Is this the best approach?
In the linked AskUbuntu question, the author knew which dependency was missing because he was trying to install a 32-bit application on a 64-bit Ubuntu installation, and, to quote him:
some 32 bit libraries are absent in Ubuntu 64 bit.
So he needed to install them.
However, to answer your questions:
Yes, there is a way to detect missing dependencies or to get a list of them.
The package management system apt, used in Debian-based Linux distributions, is a clever system, where it will automatically detect if currently installed packages have missing dependencies (even if you have installed them using dpkg, and not apt-get). Let's say that you've installed a package, without its dependencies, then the next time you execute apt-get upgrade, you'll get an error similar to this:
The following packages have unmet dependencies:
package1 : Depends: package2 (>= 1.8) but 1.7.5-1ubuntu1 is to be installed
Indicating that package1 depends on package2, and package2 (namely, the newer version in this example) is not installed. Usually, to fix this, you execute the command sudo apt-get install -f, which instructs apt-get to attempt to retrieve and install the missing packages.
The apt suite, as well as dpkg, provides a neat way to list the dependencies of a package.
For apt, the command is:
apt-cache depends <packagename>
This will check the package in the repositories and list the dependencies, as well as "suggested" packages. If you really want to filter out the dependencies alone, you could filter the output by doing this: apt-cache depends <packagename> | grep Depends. Here's an example output:
alaa@aa-lu:~$ apt-cache depends vlc vlc Depends: fonts-freefont-ttf Depends: vlc-nox |Depends: libavutil51 Depends: libxpm4 Depends: zlib1g PreDepends: dpkg Suggests: videolan-doc Recommends: vlc-plugin-notify Recommends: xdg-utils Breaks: vlc-data Breaks: vlc-nox Replaces: vlc-data Replaces: vlc-nox
Output is cut down for brevity.
For dpkg, the command to run it on a local file is:
dpkg -I file.deb | grep Depends
dpkg -I file.deb returns a lot of information about this .deb file, so we filter it to only look at the dependencies.
Since apt is actually just a front-end for dpkg, both these commands essentially do the same exact thing, they go look at the .deb file of the application to find out what dependencies it needs, except apt-cache will look in the repositories. These "dependencies" are listed inside the .deb file as metadata, that is why even if you have manually downloaded and installed an application (which is usually a .deb file, so you'll be installing it using dpkg and not apt) from a website (for example, Google's Chrome browser from Google's website), apt will still find out that there are missing dependencies, by analyzing the installed packages.
I'm not well versed with all this computer architecture stuff, but in the case of Java in that question, it's really about the 32- and 64-bit architecture. To quote the answer from stackoverflow:
You're running on a 64bit system without a 32bit runtime environment.
That specific library, that needed to be installed, was not included in the "Depends" part of the installation package, because he was installing a 32-bit application on a 64-bit system. So, extra troubleshooting was needed to find the culprit, hence the use of readelf and ldd. However, these are probably more specific to libraries, and remember that "dependencies" are not always "libraries", but could be other applications. So "Is this the best approach?", I doubt it; I think it's only best when extra troubleshooting is needed.
