Question

I have a library, foo, for which I’ve produced a static object (libfoo.a).

I have a second library, bar, for which I’ve produced a shared object (libbar.so), which picks up some symbols from libfoo.a.

I have a third library, baz, for which I’m trying to link to bar. Upon invoking the linker, I get errors about symbols missing in bar (corresponding to symbols that are in foo). nm tells me that these symbols exist in libfoo.a, but not in libbar.so; however, there are some symbols from libfoo.a in libbar.so.

Why aren’t all symbols being copied?

Answer 1

A .a library is not a “static object”. A .a file is an archive, similar in theory to tar, but a different format and generated by the ar command. Each object in the archive is distinct and individual. Usually these objects are .o files, which are compiled, unlinked objects. All the symbols in one of those .o files would be included in another files during linking (ld). But not all objects in an archive would be required during linking, the symbols in the other object files would not be seen in the linked file.

For example, in libdialog.a, there are mouse.o and columns.o object files. Your program uses columns, but not the mouse functions. So your program includes all the symbols in columns.o, but none of the symbols in mouse.o are included.

With a “shared object” (.so), it is a single object, so linking against it will include all the symbols in the object, needed or not. In the example above, if we linked against libdialog.so, then the program would include the symbols from both columns.o and mouse.o even though the mouse based code is not used.

When generating a shared object (.so), the same linkage rules apply when using an archive (.a). So the .so file will only include the symbols in the .o files in the archive that are used.