[CMake] Does find_library check that a found library does in fact link?
Michael Hertling
mhertling at online.de
Tue Oct 4 00:22:44 EDT 2011
On 09/29/2011 09:22 AM, Hendrik Sattler wrote:
> Zitat von Michael Wild <themiwi at gmail.com>:
>> Just a few of my thoughts on this:
>
> Same for me.
>
>> - 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.
>
> People tend to misunderstand the purpose of build systems like CMake
> and autotools. They try to make the detection bullet-proof and most
> likely fail. You can see that this is wrong by looking at those auto*
> setups that take ages to detect all possible header files and use an
> ifdef hell to handle that in the code, run lots of link and
> symbol-finding tests, and still fail on conditions that the author
> simple didn't consider or know.
A concrete example: Several years ago, I worked with an X11 system
which - besides TCP/IP - was aware of DECnet, and pretty nobody has
taken into account that there might be a dependency of libX11.so on
libdnet.so. Consequently, I had countless packages - also from highly
respected projects - that needed to be configured with LDFLAGS=-ldnet.
Usually, that's all there was to it, and I was perfectly okay with it,
i.e. I wouldn't expect from a project's configuration to take DECnet
into consideration just because the project is configured for X11.
> I prefer option 1. It's not CMake's duty to detect or paper over
> messed-up systems. That's the administrator's job!
> BTW: running "ldconfig -v" on Linux likely tells you about the
> dangling symlink.
Absolutely. Moreover, there are trivial day-to-day situations where
even the most sophisticated configuration can't succeed, e.g. if the
project needs a package that's simply not installed. In such a case,
administrative action must be taken anyway, either one installs the
package by oneself or asks the admin to do so. Therefore, it is my
personal opinion that one should expend a reasonable effort to fit
a project for the common configurational pitfalls, but trying to do
as much as possible in this regard will become counterproductive at
a certain point, in particular if one could easily counteract with
administrative means.
There is no such thing as portable software,
only software that has been ported.
-- Unknown
[Annotation to chapter 1 of the imake book]
> What's next? Asking for a syntax check of found header files so that
> the compiler doesn't complain on broken header files?
Equipping FIND_PATH() with a check if the file for which the path is
to be returned is a valid header, and equipping FIND_PROGRAM() with
a check if the program to be returned is a valid executable - with
the same justification as for library checks in FIND_LIBRARY().
Regards,
Michael
More information about the CMake
mailing list