Resolving a hostname (DNS lookup)

A hostname can be resolved to an IP address via DNS with the nslookup command:

    nslookup example.com

The output identifies the address of the server:

    Server:         161.44.124.122
    Address:        161.44.124.122#53

The file /etc/resolv.conf is used to configure name servers.

List functions in a library, object, or executable

The nm command may be used to list the symbol table in any object file (including static libraries, shared objects,  and executables). The symbol table includes global variables and public functions.

nm myexe

nm libxyz.a

nm libabc.so

See the nm man page for more information.

Executable 32-bit or 64-bit

An easy way to check if an executable is compiled for 32-bit vs. 64-bit is the file command:

file myabc 

The same command may be run on a library:

file libxyz.so

The output of the file command lists information such as whether the file is an executable or a shared object, whether or it is dynamically linked (using shared libs), etc.

/usr/local/lib

In some Linux distros, namely Red Hat, the /usr/local/lib directory is not included in the built-in library search path. Using a shared object file in this directory may cause an error. To solve this problem, either move the library in question to one of the built-in library search directory (/usr/lib or /lib) or add /usr/local/lib to the LD_LIBRARY_PATH environment variable.

Cannot open shared object file

Ran into trouble trying to run an executable the other day. Hit the following message:

libxyz.so: cannot open shared object file: No such file or directory

Made sure that the shared object file in question actually did exist:

ls /lib | grep libxyz.so

ls /usr/lib | grep libxyz.so

 Turns out that the library was not in any of these standard directories, but existed in a separate directory. Made sure this separate directory was in the LD_LIBRARY_PATH:

echo $LD_LIBRARY_PATH

The directory with the library was part of the load library path, but still no luck launching the executable. The runtime linker responsible for loading up the shared objects uses cached information about the objects rather than sifting through the directory structure. The cache information can be updated by running:

ldconfig

Running ldconfig crashed with a SIGBUS error. A little odd. Used the strace utility to list all the system calls made by ldconfig before the crash:

 strace ldconfig

The last "open" system call before the crash was to some random library I had never heard of or even used:

 open("/lib/libabc.so", O_RDONLY)

Running the "file" command on this mysterious library reveals some deeper problems:

file /lib/libabc.so

Solution: copied the same library over from another system and re-ran ldconfig.

In the end, libabc.so was repaired and libxyz.so was perfectly fine. Retried the executable and it started up with no complaints.