from the document:

Declaring a library dependency that you don’t actually need currently has no visible consequences. Somewhat obviously, the tree still links.

 

Unnecessary private edges are almost entirely harmless, except perhap for some tiny overhead of including the symbols exported from the library among the candidate symbols during linking. 

 

However, unnecessary public library edges are actively harmful. If library A declares a public library dependency on B when it doesn’t need to, then every library that picks up, directly or transitively, a dependency on A will also pick up a dependency on B and all of B’s transitively exported dependencies. Suddenly everything that uses A can get away without declaring proper dependencies for things from B and its transitive includes.

 

Unfortunately, resolving these sorts of errors is extremely difficult. In theory it looks like it would be straightforward: if A does not make direct use of any symbols from B, and if the interface to A does not induce a dependency on B to users of A, then B is an unnecessary dependency in A. This simple rule breaks down entirely, however, in the presence of static initializers: even though B may not satisfy any symbolic references in A (or A’s users), it may be necessary for B to be present in the image anytime A is present so that B’s initializers can configure state that A depends on.

 

Without a mechanism to identify and validate the initializer dependency graph threaded through the library dependency graph, it is impossible to ever safely remove an edge from the graph. After removing such an edge, the graph may link, and the process may start up (especially if the initializer is a C++ initializer and not a MONGO_INITIALIZER, but then fail at runtime since an entire but rarely used subsystem (ldap?) is no longer properly configured.

 

We currently have no technology that allows us to identify and validate the correctness of the link graph with respect to initializers. Further discussion on this topic will be deferred to the end of this section.

 

Due to the technical complexity of this problem, it seems advisable to address it near to the end of the project, if a resolution to the initializer problem is identified. Without a solution, this result is disappointing, as it means we cannot reduce the total number of direct edges declared in the graph.