[CMake] Recursive dependencies and static libraries

Jed Brown jed at 59A2.org
Wed Nov 5 15:29:13 EST 2008


I hope clarifies the core problem I rambled on about in my last message.

Suppose I am building project Foo which depends on libA which has an
optional dependency on libB.  It looks like everyone just does

  find_library (A_LIBRARY A)

and calls it good.  If libA is a shared library, the linker can track
down the recursive dependencies so everything will just work, but if
libA is static, then libB must be passed to the linker *if* libA was
built with libB.  How should one handle this logic?  What I've been
doing is parsing the link line provided by libA's build system and
adding all the libraries to A_LIBRARIES.

For shared libs, it really is better to only pass libA to the linker.
Since Foo will never call into libB directly, I could upgrade libA to
link against libB2 (or reconfigure libA to not link against libB, then
uninstall libB) and as long as libA maintains a stable ABI (doesn't bump
soname), Foo would not need to be relinked.

But I have to support systems which only have static libs so I can't
rely on the linker to track down the recursive dependencies.



Here is an extremely simple test case that is broken on every
platform where libtiff is a static library.

  http://59a2.org/files/cmake-tiff.tar.gz

CMake configures successfully, but the build fails with lots of
unresolved symbols.  The user needs to manually add the dependency graph
of libtiff (libjpeg, libz, libm) to an advanced variable to link
properly.

Do others not consider this to be broken behavior?  What if the
dependency graph is dynamic (depends on configuration) and may consist
of 40 libraries scattered throughout the filesystem, but there is an
algorithmic way to find them (by parsing a link line provided by the
libA build system)?  It seems to me that all modules should be providing
this dependency graph when they are finding static libraries, otherwise
the user is left with a nightmare of manually tracking it down.  Are
there no CMake developers on systems without shared libs?

Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081105/8e430b69/attachment.pgp>


More information about the CMake mailing list