Depends.exe for GNU/Linux

I need to distribute a binary file for GNU/Linux...

On Windows, I could run a utility named "depends.exe" that would verify all dependencies that the file have, thus I would be able to know what to ship with the file, how I do the same with GNU开发者_JS百科/Linux?

Clarification: I did not mean LITERALLY distributing it (unless it is some certain library that never generate problems, like... libThatOnlyMySoftwareUseVersion0.00042895.08421thatnoonehas Kinda like figuring that the users would need...)

The utility you are looking for on Linux is called ldd. However, do your users a favor and don't think about distributing libraries with your program. Require your users to install the prerequisites through the proper channels. Or, better yet, package your software using an appropriate installation system like RPM, apt, or portage (I'm assuming you can't use source distribution and the autotools); doing so allows the package management system to automatically resolve dependencies by pulling in any required libraries.

Distributing versions of libraries using ad-hoc schemes is going to only cause problems for end users (something akin to DLL hell on Windows). They can end up with conflicts, crashes, and possibly security holes.

You can use ldd to figure out what libraries your binary depends on so that you can set up the proper dependencies when you make your packages (some packagers, like RPM, actually do this for you).

On linux you can try ldd.

typically you would build a linux binary for a particular distribution of linux, and just provide your own binary, and require users to install the other pieces. If you are using a system that uses rpm packages, you want to read up on how to build RPMs, if you are using a Debian variant then you want to see how apt binary packages are built.

If you want to manually check what libraries your binary is linking against then:

    ldd /whereever/is/your/binary

will give you a list of linked libraries for a dynamically linked binary. but you DO NOT want to distribute most of these as it's like trying to redistribute system32.dll or windows.dll bad bad idea :^)

If your executable depends on some libraries from Debian packages, and you want to find out which packages they are, you can use something like this:

dpkg --search `readelf -d $PATH_TO_EXECUTABLE | egrep --only-matching '[^[]+\.so\.[^]]'` | egrep --only-matching '^[^ :]+' | sort | uniq

I would say that while I understand the intent of how linux package distros should work, this is in contrast to the modern app-package scheme that ALL app-stores (Windows, Apple, Android) use to package the entire application AND all dependencies into the redistributable package for download from the app-store. This has been proven to be the least dll-hell-y way to have applications with different versions of the same dependency installed side-by-side without conflict, as well as providing the store-owner a way of providing some level of assurance that they know what the app-code is doing, and therefore they are willing to stand behind the apps on their store.

Just an observation on how other platforms are doing things, and linux might want to take note.

The "shared" library model is an artifact from the ancient past when disk space was expensive, and every byte counted. Disk space is cheap now, and there are other considerations (like security and less complex app-installs).

So, it really depends on how you deploy your "3rd party" libs. No, you don't want to deploy 3rd party dependencies to the common usr/libs directory, but deploying them in your app's directory makes some sense, and won't lead to the dll-hell concerns raised above, if your app only looks in it's own directory for libs.