Building a library with undefined symbols (C++)

Question

I have the following linear dependency tree for a project/product in C++ :

Product <- C <- B <- A

A, B and C are each build separately. A,B and C are linked in the final Product and it works fine.

Now when I inspect e.g C with nm:

http://linux.about.com/library/cmd/blcmdl1_nm.htm

I get a bunch of undefined symbols as expected since its first when I assemble the Product that the required dependency tree are linked together.

Are there any convention that a lib must always have all its symbols defined (meaning that dependencies must be linked into the consuming lib before being deployed)? Or is it acceptable to deploy "naked" libs that are linked together with their dependencies at a higher level?

Answer 1

Coming from the Windows world:

I've seen this used inside a company. Separate the code base into several static libs and link them all together in different combinations depending on what each product needs.

I've also seen it in public SDKs, where the functionality is divided among several DLLs, some of which depend on each other, others are optional depending on what functionality you need.

It wouldn't seem unusual to me.

Answer 2

I've seen that too. That happens in a lot of legacy software. The library was probably well designed when it started, then some software mods were made later and things got a little sloppy. It all compiles and runs but the libraries do not quite encapsulate whatever set of functionality they originally did.

It's a business decision. To fix it, it may take a lot of work and retesting to end up with the same product. It makes better sense to slowly refactor the libs where it makes sense over time... or completely replace them when the next major release of features affects the libs.