Wow… so far, off to a bad start.
We’ll call this a place-holder for now…
ELF, ld & shared object fun
Most developers have encountered LD_LIBRARY_PATH either in testing shared libraries used in their project or in development of their own code. It is used to instruct the runtime linker to search for libraries in the paths included in this environmental variable. There are many discussions online as to why use of LD_LIBRARY_PATH can be bad, as you may inadvertently load the incorrect copy of a library. Some commercial software requires it to be set when custom installation paths are used, but there should be little need to use it when you have the ability to compile the code.
LD_PRELOAD is similar to LD_LIBRARY_PATH, but rather than merely suggesting the path in which to find libraries the code is linked with, it loads the specified library prior to loading any of the application libraries. This is particularly useful in debugging or other situations, because it allows you to easily replace specific functions (i.e. malloc & free) without implementing your own copy of the entire library which contains them.
ldd - print shared library dependancies
nm - list symbols from object files
readelf - display information about the ELF file
objdump - display just about anything from an ELF file