[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Question regarding interdependent convenience libraries

From: Scott D. Fleming
Subject: Question regarding interdependent convenience libraries
Date: Wed, 2 May 2007 17:59:33 -0400

I am working on a package that contains a family of related C++
programs. I include several convenience libraries in the package. The
convenience libraries are interdependent and the various programs
depend on different subsets of the convenience libraries. To get a
better idea of what I'm talking about, consider these libraries and
programs and their direct dependencies.

  libA -> { }
  libB -> { }
  libC -> { }
  libX -> { libA , libB }
  libY -> { libB , libC }
 prog1 -> { libX , libY }
 prog2 -> { libA , libX }

The package's directory hierarchy looks like this:


Using the GNU build system, I had thought the way to handle this was
to write files for each lib such that the direct
dependencies were listed using *_LIBADD, and write files
for each prog such that the direct dependencies were listed using

For example here is libX's

 libX_la_SOURCES = ...
 libX_la_LIBADD = @top_builddir@/src/A/ \

And, here is prog1's

 bin_PROGRAMS = prog1
 prog1_SOURCES = ...
 server_LDADD = @top_builddir@/src/X/ \

In fact, this setup has seemed to work on all the systems I've tested
it on (e.g., GNU/Linux and Solaris).

However, I am concerned with the fact that different pairs of
libraries contain duplicate sub-libraries (e.g., libX and libY both
contain libB) and some programs will link with such pairs of libraries
(e.g., prog1 links with libX and libY). Additionally, I am concerned
by the sort of linking done to build prog2 (i.e., prog2 links with
libA and libX, which already includes libA).

Is libtool or the underlying linker smart enough to recognize and
ignore the duplicate libraries?

Or, do I have a problem with my setup? If so, can anyone suggest a
better one? (I am familiar with the technique that uses a top-level
convenience library that aggregates the sub-libraries; documented

Please keep in mind that one thing I like about the above setup is
that each library and program's direct dependencies are listed locally
in its I'll be curious to know any alternate solution
that can also achieve this.

Thanks, Scott

reply via email to

[Prev in Thread] Current Thread [Next in Thread]