How do library dependancies work when linking?

Question

I have a library libmya.so and a library libmyb.so. The functions in libmyb.so depend on functions in libmya.so. Also I have an executable myexe which depends on libmyb.so. When I make these libraries, in which rules should I put the -l options?

Should it be 1):

libmya.so: $(OBJ_FILES)
 $(CPP) $(LDFLAGS) -o $@ $^
libmyb.so: $(OBJ_FILES)
 $(CPP) $(LDFLAGS) $(LIBS) -o $@ $^ -lmya
myexe: $(OBJ_FILES)
 $(CPP) $(LDFLAGS) $(LIBS) -o $@ $^ -lmyb

or 2)

libmya.so: $(OBJ_FILES)
 $(CPP) $(LDFLAGS) -o $@ $^
libmyb.so: $(OBJ_FILES)
 $(CPP) $(LDFLAGS) $(LIBS) -o $@ $^
myexe: $(OBJ_FILES)
 $(CPP) $(LDFLAGS) $(LIBS) -o $@ $^ -lmya -lmyb

or some other combo?

• Fred Nurk: Why are you using CPP? That is conventionally the C preprocessor; CXX is conventionally the C++ compiler.
• Matthew Smith: @Fred Nurk: It was like that when I got here! Thanks for the tip.
• mgiuca: What operating system are you using? I assume Unix since you are dealing with so files, but it doesn't hurt to clarify.

Answer 1

I would go with option 1 (though option 2 works, I wouldn't recommend it since then anybody who links the exe needs to remember all the transitive libraries required).

However, this advice is only for making an so file, as you do above. so files (shared objects) are "intelligent" libraries, much like executables, except they don't have a main. so files can link to other libraries (like executables), and when an executable links to an so file, it will automatically recursively include the dependencies of the so file.

Therefore, an so file you create should be linked with all of its dependencies.

A "dumb" library, such as an a file (static library) is a different story; then you need to do all the linking in the executable (option 2).

I recommend you use the ldd tool to investigate the dependencies of both the executable and the so file to see how this works.

For a real-world example of why option 1 is better, try ldd /usr/lib/libpng.so. Note that libpng is linked with libz. If it wasn't, anybody who ever links against libpng would also need to link against libz. As it is, you can link against libpng without even knowing that libz is involved.

Answer 2

Libraries are not dependant of each other when you build them. It is de executable (exe or dll) that is dependant on them. Libraries are just collections of functions and/or data. They just have to be there when their contents is used by the exe/dll at link-time (from where is not important). Libraries are not linked (when building them) ,the object-files that comprise them archived by a librarian.

The functions in one library can use function in another library ,but only at link-time of an exe/dll will those depencies be resolved (that means that both libraries must be linked in).

• mgiuca: See my answer. Either option will work, but option 1 is much better. You aren't correct (at least on Unix, where so files exist so presumably the question is about Unix) that libraries are not linked, and are merely "dumb" collections of objects. That is true for a files but not so files. Libraries can (and should) be linked with their dependencies.
• engf-010: @mgiuca: can't ypu read ? I clearly make a distinction make a distinction between libraries and dlls. For your information dlls are executable code therefor the must be linked. Whereas libraries are merely a colection of object-files containing functions and code.
• mgiuca: Ah, I see that distinction now. It was very unclear and the terminology is wrong -- you use the word "library" as a specific term for what in Unix is called a "static library" or "archive" (an a file). You use the Windows-specific term "dll" for what in Unix is called a "shared library" or "shared object" (an so file). Since the author is dealing with shared objects, saying that libraries do not need to be linked is misleading, and doesn't answer the question.