Home » Support » Unix C Programming FAQ - Section 7

Go to the first, previous, next, last section, table of contents.


6. Use of tools

6.1 How can I debug the children after a fork?

Depending on the tools available there are various ways:

Your debugger may have options to select whether to follow the parent or the child process (or both) after a fork(), which may be sufficient for some purposes.

Alternatively, your debugger may have an option which allows you to attach to a running process. This can be used to attach to the child process after it has been started. If you don't need to examine the very start of the child process, this is usually sufficient. Otherwise, you may wish to insert a sleep() call after the fork() in the child process, or a loop such as the following:

{
    volatile int f = 1;
    while(f);
}

which will hang the child process until you explicitly set f to 0 using the debugger.

Remember, too, that actively using a debugger isn't the only way to find errors in your program; utilities are available to trace system calls and signals on many unix flavours, and verbose logging is also often useful.

6.2 How to build library from other libraries?

Assuming we're talking about an archive (static) library, the easiest way is to explode all the constituent libraries into their original objects using `ar x' in an empty directory, and combine them all back together. Of course, there is the potential for collision of filenames, but if the libraries are large, you probably don't want to be combining them in the first place....

6.3 How to create shared libraries / dlls?

The precise method for creating shared libraries varies between different systems. There are two main parts to the process; firstly the objects to be included in the shared library must be compiled, usually with options to indicate that the code is to be position-independent; secondly, these objects are linked together to form the library.

Here's a trivial example that should illustrate the idea:

/* file shrobj.c */

const char *myfunc()
{
    return "Hello World";
}

/* end shrobj.c */

/* file hello.c */

#include <stdio.h>

extern const char *myfunc();

main()
{
    printf("%s\n", myfunc());
    return 0;
}

/* end hello.c */

$ gcc -fpic -c shrobj.c
$ gcc -shared -o libshared.so shrobj.o
$ gcc hello.c libshared.so
$ ./a.out
Hello World

By far the best method if you want the library and build procedure to be anything approaching portable is to use GNU Libtool. This is a small suite of utilities which know about the platform-dependent aspects of building shared libraries; you can distribute the necessary bits with your program, so that when the installer configures the package, he or she can decide what libraries to build. Libtool works fine on systems which do not support shared libraries. It also knows how to hook into GNU Autoconf and GNU Automake (if you use those tools to manage your program's build procedure).

If you don't want to use Libtool, then for compilers other than gcc, you should change the compiler options as follows:

AIX 3.2 using xlc (unverified)
Drop the `-fpic', and use `-bM:SRE -bE:libshared.exp' instead of `-shared'. You also need to create a file `libshared.exp' containing the list of symbols to export, in this case `myfunc'. In addition, use `-e _nostart' when linking the library (on newer versions of AIX, I believe this changes to `-bnoentry').
SCO OpenServer 5 using the SCO Development System (unverified)
Shared libraries are only available on OS5 if you compile to ELF format, which requires the `-belf' option. Use `-Kpic' instead of `-fpic', and `cc -belf -G' for the link step.
Solaris using SparcWorks compilers
Use `-pic' instead of `-fpic', and use `ld -G' instead of `gcc -shared'.

(Submission of additional entries for the above table is encouraged.)

Other issues to watch out for:

6.4 Can I replace objects in a shared library?

Generally, no.

On most systems (except AIX), when you link objects to form a shared library, it's rather like linking an executable; the objects don't retain their individual identity. As a result, it's generally not possible to extract or replace individual objects from a shared library.

6.5 How can I generate a stack dump from within a running program?

Some systems provide library functions for unwinding the stack, so that you can (for example) generate a stack dump in an error-handling function. However, these are highly system-specific, and only a minority of systems have them.

A possible workaround is to get your program to invoke a debugger on itself -- the details still vary slightly between systems, but the general idea is to do this:

void dump_stack(void)
{
    char s[160];

    sprintf(s, "/bin/echo 'where\ndetach' | dbx -a %d", getpid());
    system(s);

    return;
}

You will need to tweak the commands and parameters to dbx according to your system, or even substitute another debugger such as gdb, but this is still the most general solution to this particular problem that I've ever seen. Kudos to Ralph Corderoy for this one :-)

Here's a list of the command lines required for some systems:

Most systems using dbx
"/bin/echo 'where\ndetach' | dbx /path/to/program %d"
AIX
"/bin/echo 'where\ndetach' | dbx -a %d"
IRIX
"/bin/echo 'where\ndetach' | dbx -p %d"