Tuesday, August 10, 2010

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:


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

Monday, August 9, 2010

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.

Friday, August 6, 2010

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.


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.

Thursday, August 5, 2010

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:
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:
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.