[CMake] Recursive dependencies and static libraries

Jed Brown jed at 59A2.org
Thu Nov 6 15:03:02 EST 2008


On Thu 2008-11-06 13:18, Bill Hoffman wrote:
> Jed Brown wrote:
>
>> The FindPkgConfig.cmake module looks broken too, it assumes that
>>
>>   -L/A -la -L/B -lb
>>
>> is equivalent to
>>
>>   -L/A -L/B -la -lb
>>
> I don't see where the above would fail.

If /A/libb exists, but is ABI-incompatible with /B/libb.  This happens,
for instance, when /A is a system directory and /B has libraries built
against a particular MPI.  /A/libb may be a version of the library built
without MPI or against the wrong implementation.  This situation is very
common on clusters where every package is built with every combination
of compilers and MPI implementations.

>> To get fully resolved paths, I think it needs to do something like what
>> is in my FindPETSc.cmake.  PkgConfig defines PREFIX_STATIC_* which is
>> good, but this means that whoever is writing the FindXXX module needs to
>> branch on whether the libs they search for are actually resolving to
>> static libs.  This *always* needs to be done, but it's not done in the
>> modules included with CMake (FindLibXslt and FindLibXml2).
>
> So, exactly what are you proposing?
>
> Here is what I understand:
>
> - If you link to a static library, you need to link to all static  
> libraries that that library uses in the correct order.
>
>
> That information is stored in several places:
>
> - pkg-config
> - in makefiles distributed with the project
> - other config files?
> - cmake projects support the export and import of depend info on libraries
>
> To me this a very library specific issue do you have some general way to  
> solve this problem?  What tools/functions would you like to see in CMake  
> to address this issue?

I have two proposals which would make a big difference.  The first is
easy and applies to pkg-config, makefiles distributed with the project,
and wrapper-compiler schemes:

  resolve_link_line (FOO_RECURSIVE_LIBS "${FOO_RECURSIVE_LINK_LINE}")

This can be pretty much what's implemented in FindPETSc.cmake: parse the
link line one token at a time, for each -L/path/to/XXX entry, add
/path/to/XXX to a list of HINTS, for each -lxxx, use find_library() with
the current HINTS.  It must be guaranteed that the libraries are
resolved the way the compiler would have resolved the link line.
FindPkgConfig should use this (with --libs, handling --libs-only-l and
--libs-only-L separately is broken) as well as FindMPI and others.


The second is harder (to name as well)

  augment_c_source_compiles (FOO_LIBRARIES
    "${FOO_INTERFACE_LIBRARIES}"
    LIBRARIES "${FOO_RECURSIVE_LIBS}"
    "/* Some test program */")

FOO_INTERFACE_LIBS contains all libs that the test program calls into.
This might be only be a subcomponent of FOO.  FOO_RECURSIVE_LIBS
contains a possibly excessive list of libraries which are or might be
dependencies of FOO_INTERFACE_LIBRARIES.

On output, FOO_LIBRARIES should contain everything in FOO_INTERFACE_LIBS
plus any libs in FOO_RECURSIVE_LIBS that are required to link the test
program.  When FOO_INTERFACE_LIBS are shared, it is (in principle)
possible to just ignore FOO_RECURSIVE_LIBS (i.e. the program should
compile with only FOO_INTERFACE_LIBS).  When some/all of
FOO_INTERFACE_LIBS are not shared, it will usually be required to
include link some FOO_RECURSIVE_LIBS.  A working implementation could
just concatenate the two lists, a better implementation would eliminate
unneeded dependencies (by exploring subgraphs or exploiting
platform-specific linker features).


Accepting optional arguments MODULES and NAMES would help Csaba and be
handy for lots of simple libraries.  It would make his FindTIFF module
look like

find_library (TIFF_LIBRARY tiff)
augment_c_source_compiles(TIFF_LIBRARIES
  "${TIFF_LIBRARY}"
  MODULES JPEG ZLIB  # optional recursive dependencies
  NAMES m            # libm.a also needed with static libs
"
#include <tiffio.h>
int main() { TIFFClientOpen(0, 0, 0, 0, 0, 0, 0, 0, 0, 0); return 0; }
")


Comments?

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/20081106/31bdec5e/attachment-0001.pgp>


More information about the CMake mailing list