[CMake] Does find_library check that a found library does in fact link?

[Clifford Yapp]

On Thu, Sep 29, 2011 at 2:59 AM, Michael Wild <themiwi at gmail.com> wrote:

>
> Just a few of my thoughts on this:
>
> - There are several ways to handle dead symlinks:
>  1. Don't check, let the linker complain (status quo)
>  2. Check whether the found library is a symlink, and if not valid,
>     remove it silently from the list of candidates. Can be very
>     surprising and will likely result in quite a few bug reports
>     about CMake not finding a certain library that is "clearly" there.
>  3. Like 2, but warn about the issue. Possibly very annoying.
> I don't know which option to prefer (perhaps somebody finds another one
> that is better?). IMHO bogus symlinks to shared libraries constitute a
> real problem of the library installation, so CMake shouldn't just paper
> over it by silently skipping the dead link, proceeding to the next
> candidate which rules out option 2 for me. Also, option 3 can be
> troublesome in automated setups where no user actually reads the CMake
> output.
>

What about warning by default, but accepting a flag to be quiet about it if
the user specifically requests those warnings not be issued?

The issue may "surprise" people, but if they don't understand what a bad
symlink implies they'll be just as surprised (and confused) when their build
fails but the file is "clearly there."  Better to know up front before
putting the extra time into running the compile, IMHO...


>
> - Concerning link-tests:
>  1. Only possible with shared libraries
>

That's OK - we can still do it for those libraries.


>  2. Some shared libraries require special linker flags which CMake
>     would require the user to provide. Not so much of an issue, since
>     the user needs to provide them anyways.
>

Right.  In fact, a linker failure because of flags not supplied is
information the dev needs in any case, so I don't really see that as a
problem.


>  3. Some shared libraries on *NIX systems are under-linked, i.e. they
>     require additional libraries to be specified on the link line.
>     Again, CMake can't know about those (as with static libraries).
>

It might be worth looking at AC_CHECK_LIB and how it handles such cases.
One approach might be to support a flag to find_library to specifically skip
link checking for that particular test, if the dev knows in advance it
doesn't link in isolation.


>  4. Last, but not least, linking can be a very expensive operation.
>

That's the tradeoff - better results or more time.  Perhaps a global
CMAKE_CHECK_SHARED_LIBRARY_LINKING variable could turn testing on or off
globally?


> All of these factors make it very hard to come up with a set of tests
> that produces no false negatives (i.e. *never* discards a library that
> is actually valid). I don't care about false positives so much, because
> the linker will complain loudly about those, but if CMake "refuses" to
> find a valid library, that is a *real* problem.
>

What about having the shared library checking variable off by default, but
allowing a project to enable it if they want to deal with the issues of
making sure the tests are valid?  Once the fundamental mechanisms to enable
such tests are in place, the burden then shifts to the project to make sure
they're feeding in the right linker flags and such to correctly test a valid
library.  Some of them will want to pay both the configure time costs and
the developer time costs to have those checks in place.

Cheers,
CY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110929/546ff298/attachment.htm>