How to check which binaries depend on certain files in /lib

You need to instruct your system where to find dynamic libraries. System-wide directories like /usr/lib are in the default search path for dynamic libraries, but if you want to add custom directories, you need to declare them by listing them in the environment variable LD_LIBRARY_PATH. This is a colon-separated list of directories, like PATH.

export LD_LIBRARY_PATH=/home/mks/myGL/oglpg/lib

Put this line in your ~/.profile or wherever you define environment variables. You can also run it in a shell and it'll apply to all programs started from that shell.

Alternatively, when you build a program using the library, register its location on your system.

g++ -Wl,-rpath,/home/mks/myGL/oglpg/lib … -L /home/mks/myGL/oglpg/lib -lGLEW

The chapter on shared libraries in the Program Library Howto may be of additional help.

Your understanding is mostly correct, but there are a couple of extra things to consider:

1. 'binary' refers to something that isn't human readable. This usually refers to machine code, but many other files are also binary files in this sense, with most multimedia formats being a good example. The FHS however has a more specific usage for the term.
2. Libraries can be binary code. In fact, most of the stuff in /lib is going to be libraries compiled to machine code.
3. While things like cat are used in shell script like calls to code in libraries, they are not libraries in the FHS sense because they can be run by themselves.

As a result of these points, the more common terminology among people who aren't writing standards documents is:

• Object files: These are natively compiled machine code, but may not even run or be callable. They typically have a .o extension unless they fall into one of the other categories, and are almost never seen on most systems except when building software. I've listed them here because they're important to understanding a few things below.

• Executable files: These are files consisting of mostly self contained code that can be run directly. They may be either specially formatted object files which can be loaded directly by the kernel (things like cat, bash, and python are all this type of executable), or are interpreted by some intermediary program that is itself an executable (Minecraft, pydoc, and cowsay are all examples of this type of executable). Executables of the first type almost never have a file extension on UNIX systems, while executables of the second type may or may not. This is what the FHS refers to as 'binaries'. They can be run from other executables, but require calling special functions to invoke them (fork() and exec() in C and C++, things out of the subprocess module in Python, etc) and run as a separate process.

• Libraries: These are files that contain reusable code that can be invoked by another library or an executable. Code in libraries is invoked (mostly) directly by other code once the library is loaded (referred to as 'linking' when talking about compiled code), and runs in the same process as the code calling it. There are three generic types of libraries:

  1. Static libraries: These are the original variety. They consist of an archive file (usually AR format) with a large number of object files inside, one for each function in the library. The object files get linked into the executable that uses them, so an executable that uses just static libraries is essentially 100% independent of any other code. On UNIX systems, they typically have a .a extension. The concept of static libraries doesn't really exist outside of compiled programming languages.
  2. Dynamic libraries: These are the most common type of library used today. A dynamic library is a special object file, typically with a .so extension on UNIX (.dll is the standard on Windows), that gets loaded at run time by executables that use it. Most of what you'll find in /lib on production systems is dynamic libraries.
  3. Modules: This is the equivalent of a dynamic library for an interpreted language. Handling is a little bit different than for a compiled language, and unlike with a compiled language, it's possible for a file to be both a module and an executable (see http.server in the Python standard library for an example).