[CMake] third party library dependencies

[Michael Wild]

On 21. Dec, 2009, at 12:17 , Marcel Loose wrote:

> On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote:
>> On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" <loose at astron.nl> wrote:
>>> Hi Roman,
>>> 
>>> Not in a portable way. I'm not too familiar with Windows, but on Linux
>>> you can do this when libA is a shared library that has its dependency on
>>> libB linked in (e.g. ldd libA.so will tell you this). When linking in
>>> static libraries you're out of luck. 
>> 
>> With shared libraries, you need not and *should not* explicitly link
>> recursive dependencies.  If you have both static and shared libraries,
>> the output of ldd could be used to find the recursive deps needed to
>> link statically.  This sucks and the logic to determine whether to put
>> recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is
>> insane.  FWIW, pkg-config has Libs.private for this purpose.
>> 
>> Finally, it would be nice to easily associate a symbol with a call to
>> find_library.  That is, suppose libA links to libB and libC, but libA
>> never exposes libB or libC to users.  To do the right thing (without
>> abusing ldd), FindA.cmake needs to try linking with just -lA (which will
>> work with all shared libs), then try with -lA -lB and -lA -lC before
>> falling back to -lA -lB -lC (which is required when all libs are
>> static).  A better way which does not have exponential complexity would
>> be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar"
>> belongs with a libC.  So when linking with -lA fails, libB would be
>> added exactly when B_Foo is undefined.
>> 
>> Jed
> 
> Hi Jed,
> 
> Why do you consider explicit linking of recursive dependencies a bad
> thing? It's superfluous, I agree, but there's no harm in it, right?
> 
> Best regards,
> Marcel Loose.
> 

It's called overlinking and can be a real problem for package maintainers. See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking

Michael