[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