[cmake-developers] Unexpected bad status for file DOWNLOAD for http://*.xz URLs

[Alan W. Irwin]

On 2013-07-12 10:57-0000 David Cole wrote:

>> By bringing the openssl library build in house (similar to the way
>> there is an in-house version of libcurl), I think CMake could be made
>> a lot less fragile with respect to downloading.
>
>
> The Kitware-provided binaries of CMake do currently link in openssl and support https out-of-the-box...

That's good, but....

> If a distribution-provided CMake does not build CMake with openssl
support, then that is a bug in that particular distribution’s build of
CMake. Please bring it up with them to get full https support.

I agree with your conclusion, but the story is more complicated than
that so there are issues for CMake here as well.

I just double-checked with ldd that Debian wheezy cmake links to
libcurl-gnutls.so (linked to the gnutls library to provide the
SSL capabilities) rather than libcurl.so (linked to the openssl
library to provide the SSL capabilities).  The result of my test
with the Debian version of cmake is

software at raven> /usr/bin/cmake -P test.cmake
-- [download 0% complete]
-- Download status = 35;"SSL connect error"

However, note I also got this same result when I built a version of
CMake linked to libcurl-gnutls.so so it is likely there is currently
some incompatibility between CMake and libcurl-gnutls.so to cause this
connect error issue.

The point is CMake makes it much too easy to fall into the trap of
using the libcurl-gnutls.so library rather than libcurl.so.  So to
avoid such problems in the future I recommend that either CMake
blacklist use of libcurl-gnutls.so or, better yet, solve the
incompatibility issue with it.

Another important issue is that the CMake build should include SSL
support by default (and hopefully in house so there is full control of
how SSL is built and configured for that case).  But, in any case, the
build should always warn if the resulting CMake is not going to have
SSL support.

In sum, I agree with you that all cmake users who encounter bad SSL
support for CMake for their distro version of CMake should send bug
reports to those distros about those problems.  (I am about to do that
myself for Debian wheezy.) But even more importantly, builds of CMake
with tainted support (via libcurl-gnutls) for SSL should not be
possible (which would obviously cut down on the distribution problems
for CMake), and an in-house build of SSL support for the in-house curl
build would be quite useful.  Finally, if by chance the CMake build is
configured so there is no SSL support then a warning message should be
issued.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________