| Description | Some of the code pulled in from external projects (curl, libarchive) can use openssl if it is available. In the case of curl, it checks the CMAKE_USE_OPENSSL cmake variable first to see if the user wants to allow OpenSSL to be used, which is great. In the case of libarchive, however, it does not check CMAKE_USE_OPENSSL. Instead, it blindly assumes that if it can find OpenSSL, it is allowed to use it. This is a problem for LSB builds, since OpenSSL is not part of the LSB but chances are that there are ssl libraries somewhere on the system. The result is that OpenSSL is used where it should not be enabled for LSB builds. See bug 11648 for additional context for LSB-specific issues related to libarchive.
What is needed is for Utilities/cmlibarchive/CMakeLists.txt to test for CMAKE_USE_OPENSSL before making the relevant FIND_LIBRARY calls. See attached patch against 2.8.3 sources for an example fix.
Note that the use of OpenSSL is not breaking the build, since it still manages to pull in the SSL libraries at link time. The problem i that the binaries it creates rely on the presence of SSL libraries at run time and these are not necessarily available on LSB-compliant systems. Because cmake generates Makefiles which only see the final cmake binary that is run, you cannot even use launch scripts for cmake to help it find SSL libs at run time because make later executes the cmake binary directly without the launch script. The only way to make it work is to always launch make within a shell that already has things like LD_LIBRARY_PATH already set to help it find the SSL libs cmake needs, but this can be a very annoying and seemingly unnecessary inconvenience for users (yep, this happened to us and it was not an appreciated situation by our users!). |
cm.patch [^] (736 bytes) 2011-02-07 20:28 [Show Content]