[CMake] lib dependencies

Hendrik Sattler post at hendrik-sattler.de
Thu Apr 26 13:39:47 EDT 2007


Am Donnerstag 26 April 2007 19:25 schrieb Alan W. Irwin:
> On 2007-04-26 12:40+0200 Pascal Fleury wrote:
> > Hi guys,
> >
> > It is my understanding that when an application links to a shared lib, it
> > should not have to link to any of the dependencies of that shared lib, as
> > this info is included in the *.so or *.dll.
>
> I don't know about windows, but this statement is not correct for all Unix
> systems.  Some Unix platform linkers demand all indirect dependencies
> (i.e., dependendies of libraries that your application depends on) be
> mentioned when linking your application while others do not.  Autotools
> wobbled a few times on this question even for Linux depending on their
> historical assessment of the quality of the native Linux linking and
> loading tools. Last time I looked, they did not use the indirect
> dependencies for linking on Linux.  On the other hand, pkg-config always
> provides the full list (assuming the chain of library dependencies is all
> handled by pkg-config). Further confusion about these issues exist because
> people forget that some libraries/applications will have _both_ direct and
> indirect dependencies on other libraries.

Windows needs the indirect dependencies, same as MacOS X, AFAIK.
On linux, you don't need them for dynamic linking _if_ the library does not 
export any symbol of another lib. However you always need them for static 
linking.
BTW: pkg-config will do the correct thing IF you correctly use the .private 
fields (well, most of the ones I saw did not use them at all). On linux with 
dynamic linking, it does NOT always provide the same list as with static 
linking.

> The rule that works for me with CMake is to link an application or library
> with all direct and indirect dependencies to _external_ libraries (i.e.,
> those not being built as part of the CMake build of your software package)
> mentioned explicitly. However, to link an application with dependencies to
> _internal_ libraries (i.e., those being built as part of the CMake build of
> your software package) only the direct dependencies need to be mentioned;
> CMake takes care of the indirect internal dependencies in a manner that
> seems to work on all platforms we have tried.

The problem with that is that if an ABI is update to a new version in a 
indirect dependency, you have to relink the application. If you don't link 
against indirect dependencies, you only need to replace the lib that uses 
this changed ABI. For distributions, this makes a significant difference!

GNU ld knows the options --as-needed and --no-as-needed to help you get rid of 
non-necessary indirect dependencies.

HS


More information about the CMake mailing list