[CMake] third party library dependencies

[Michael Wild]

On 21. Dec, 2009, at 14:16 , Marcel Loose wrote:

> On Mon, 2009-12-21 at 13:32 +0100, Michael Wild wrote:
>> 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
>> 
> 
> OK, I see.
> 
> This raises another question, which was already alluded to in this
> thread, and may have been asked before on this list:
> 
> Is there a way to write FindXXX.cmake macros in such a way that they
> will always return the correct list of libraries to link against? I.e.,
> a short list of direct dependencies when linking against shared
> libraries, and a long complete list of recursive dependencies when
> linking against static libraries.
> 
> Best regards,
> Marcel Loose.

I honestly don't know. I wouldn't even know how to reliably differentiate between static and dynamic libraries. AFAIK some platforms use the same naming scheme, e.g. Windows uses .lib for both, static libraries and import libraries. AIX distinguishes between shared objects (really, only an object file with shared code) and shared libraries. The former either uses .o or .so (who had THIS great idea), while shared libraries use .a as do static libraries. Very confusing: http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/getstart/overview/port_aix_obj_lib.htm

Perhaps we need some new IF(STATIC_LIBRARY <filename>) command? But then that would probably require a database with file detection magic (such as Unix file(1) command uses)

Michael