[CMake] Recursive dependencies and static libraries

[Jed Brown]

On Fri 2008-11-07 12:43, Hendrik Sattler wrote:
> Jed Brown schrieb:
> >>>> 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.
> > 
> > This can also fail, but I should have written
> > 
> >   -L/B -L/A -la -lb
> > 
> > since the existing modules are doing two things wrong.  When the
> > compiler parses the link line, it builds a stack of libraries to search.
> > This stack must be searched incrementally.
> 
> I'd ask the author of B first, why the H*** he has to use the same
> library name that is already used by A, especially since he uses A.
> That is broken in itself because if you install A and B with the same
> prefix, B is broken.

Everyone should namespace their shared libs, but that's not the issue
I'm concerned with.  Suppose I'm parsing the link line

  /opt/mpich2/bin/mpicc -L/usr/lib -lumfpack -L/opt/mpich2/lib -lhdf5

where /usr/lib/libhdf5.a exists, but is not built with the parallel
interface or is built against the default (ABI-incompatible) MPI
implementation which resides at prefix=/usr.  Umfpack is not a parallel
library so I can't expect users to install a copy in /opt/mpich2 just so
the third-party library whose link-line I'm parsing can be linked
against the version sitting in /opt/mpich2/lib.  However, it's essential
that -lhdf5 resolve to /opt/mpich2/lib/hdf5.a otherwise everything will
build successfully but my user will have a binary which seg-faults.

> If you really need such specific linker behaviour (and who tells you
> that all linkers behave like this?), you actually already messed up.

The semantics are required for many linking cases such as variants on
the example above.  It's essential that they are resolved the way the
linker will resolve them.  Also remember that I'm parsing the link line
from an interface library; I don't have control over what's there, but
the interface library is asserting that if I link my library with
precisely that link line, I will have a working binary.  CMake requires
every FindXXX.cmake module to resolve the link lines to absolute paths,
not respecting linker semantics in such circumstances is a bug.

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/20081107/b7e25eb4/attachment.pgp>