No, it can't fully automatically infer dependencies.
If it had been packaged, apt-get build-dep oprofile
would have helped. If you can find a package elsewhere, you can look up the dependencies there. For example, if the package exists in the next release of your distribution. e.g. here:
http://archive.ubuntu.com/ubuntu/pool/universe/o/oprofile/oprofile_1.0.0-0ubuntu9.dsc
(and if you plan on compiling things yourself, always consider upgrading to the latest version first!)
Other than that it requires a little bit of experience to figure out. configure
scripts unfortunately won't tell you the package names, but usually it's quite easy to find. Also use the search functions on the distribution web pages - they can tell you which packages contain a certain file name.
Instead of iterating through configure
attempts, it may be more convenient to look at the configure.ac
file, from which the script was generated (and which usually is much shorter). You may be able to discover some optional functionality only offered if certain libraries are installed and some flag is given.
LIBERTY_LIBS="-liberty $DL_LIB $INTL_LIB"
BFD_LIBS="-lbfd -liberty $DL_LIB $INTL_LIB $Z_LIB"
POPT_LIBS="-lpopt"
are typical library dependencies.
AC_ARG_ENABLE(gui,[ --enable-gui compile with gui component (qt3|qt4|yes|no),
if not given or set to yes, gui defaults to qt3],, enable_gui=qt3)
indicates that you may also want to consider QT dependencies if you want a GUI.
Many packages contain special configure
script that intent is to check whatever dependencies are installed on host machine. Others go through other mechanisms, which usually mentioned in README or INSTALL files inside a source package. Few can go and be compiled as standalone programs and they do not try to detect dependencies or they have no any.
If you pick up code from GitHub, then you should be ready for incomplete code that ends up not compiling like that. Then, if you clearly can't name what that file is from which dependency (and code you're downloaded has no documentation), you can only google it. Also, many header file names are remembered as your Unix experience grows :-)
Reasonable packages have scripts (or other mechanisms) to check for dependencies and/or documentation which says what dependencies you will need, incomplete or poor packages do not have that at all.
Best Answer
Arbitrarily copying
.so
files to system-wide directories is not a good practice as it will copy shared libraries to the destination system without the Package System Control awareness, thus it can cause conflicts with installed software and may lack other dependencies you cannot easily map manually.Your mileage may vary, but there are three different approaches you can look for:
The first is trying to install the necessary software packages that contain the compatible versions of the libraries in the destination distro. This requires root, though, that you indicated as not being an option. In any case, if this turns to be an option at some point, here are some hints to help in this approach:
ldd you_executable_file
shows the library dependencies of a specific program. You can look for packages in the distro that provides such libraries (in Fedora, for example, you can useyum provides path_to_required_file
to tell you which packages are needed to be installed.The second is trying to produce a distribution agnostic executable. For such purpose you should use static libraries instead when compiling your software. Typically you can find both shared (.so) and static (.a) versions of most of the libraries in Linux. You should use the static versions and link them as if they were object files (.o). The down side is that the generated binary will be much bigger than when using shared libraries because it will carry all the library code within itself. Additionally, it will not be sensitive to bug fixes in those libraries that are later installed in the system (this will require recompiling your program with the new fixed version).
The third option is indeed copying the libraries to the new system (even not being root) to a directory under your home dir and use the
LD_LIBRARY_PATH
and/orLD_PRELOAD
environment variables to force the dynamic linker to use your copies of the libraries. Notice that you may need to copy many libraries (which you will discover using theldd
command I mentioned above.).LD_LIBRARY_PATH
tells the dynamic linker to look at additional paths to find missing libraries.LD_PRELOAD
forces the dynamic linker to pre-load a specific version of a library overriding the system-wide version.