[CMake] recursive shared library dependencies?

[Goswin von Brederlow]

Dusan Zatkovsky <msk.conf at seznam.cz> writes:

> Hi all.
>
> I have a question about library dependencies in cmake projects on linux.
>
> Let's see an example:
>
> PROJECT ( foo )
> ADD_EXECUTABLE ( foo_bin foo.cpp )
> TARGET_LINK_LIBRARIES ( foo_bin ssl )
>
> When I am building a project by "make" command, it produces output like this:
>
> Scanning dependencies of target foo_bin
> Building CXX object foo.o
> Linking CXX executable foo_bin
>
> ... and everything is right.
>
> But on "make install", it does linking again (why?) with error caused by 

I think has something to do with fixing the rpaths but I'm not too sure.

> missing libcrypto functions. Why libcrypto isn't automatically used, when 
> libssl depends on it?
>
> Now I must write complete (external) library dependencies to TARGET_LINK 
> command for successfull build and it is tiresome.
>
> What am I doing wron?
>
> Thanks for help.

Maybe this isn't too helpfull but it might give you some background.

In Debian each binary and library must be linked against all libraries
it uses itself directly but not against libraries used indirectly (one
that is only used by a library it links too).

The reason for this is simple: The binary(A) or library(A) may not
know and must not depend on the libraries(C) used by other
libraries(B). That way if any of the libraries(C) changes and a
library(B) now uses the new one then the binary(A) or library(A) need
not be recompiled.

Example:

Libbar uses libblub and libfoo uses libbar:
  libfoo -> libbar -> libblub1

Now libbar decides to use libblurb instead:
libbar -> libblub2.

If Libfoo links against libbar and libblub you now have
libfoo -> libbar -> libblub2
       -> libblub1

and too often using libblub1 and libblub2 has desasterous effects.


So in your case your libssl might be buggy (in Debian terms).

MfG
        Goswin