[CMake] FindOpenSSL choosing unexpected OpenSSL install on Windows
Jeff Trawick
trawick at gmail.com
Thu May 15 10:05:46 EDT 2014
Short form: I tell FindOpenSSL where to look by setting OPENSSL_ROOT_DIR to
point to my shiny new OpenSSL install; it ignores me and finds ancient,
vulnerable OpenSSL libraries to use instead.)
Some info about my build environment:
* pristine install of cmake 2.8.12.2-win32-x86
* "Open VS2012 x64 Native Tools Command Prompt"
* previously installed OpenSSL 1.0.1e via Win64 installer from
http://slproweb.com/products/Win32OpenSSL.html; installed to
%HOME%\OpenSSL-Win64, and apparently in registry
* trying to use my own OpenSSL build in %HOME%/PREFIXES/251 (lib, bin,
include, etc.), built in a "normal" manner: "perl Configure no-asm
--prefix=XXX VC-WIN64A" followed by "ms\do_win64a.bat"
With the following cmake invocation for Apache HTTP Server, libraries from
the old binary install of OpenSSL are being used instead of my new build:
mkdir C:\Users\Trawick\BUILDDIRS\251\httpd
cd C:\Users\Trawick\BUILDDIRS\251\httpd && cmake
-DCMAKE_INSTALL_PREFIX=C:\Users
\Trawick\PREFIXES\251 -G "NMake Makefiles"
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DO
PENSSL_ROOT_DIR=C:\Users\Trawick\PREFIXES\251 -DENABLE_MODULES=a
-DINSTALL_MANUA
L=OFF C:\Users\Trawick/svn/httpd
-- The C compiler identification is MSVC 17.0.61030.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio
11.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio
11.0/VC/bin/amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Found LibXml2: C:/Users/Trawick/PREFIXES/251/lib/libxml2.lib (found
version "
2.9.1")
-- Found Lua51: C:/Users/Trawick/PREFIXES/251/lib/lua5.1.lib (found version
"5.1
.5")
-- Found OpenSSL:
optimized;C:/Users/Trawick/OpenSSL-Win64/lib/VC/ssleay32MD.lib
;debug;C:/Users/Trawick/OpenSSL-Win64/lib/VC/ssleay32MDd.lib;optimized;C:/Users/
Trawick/OpenSSL-Win64/lib/VC/libeay32MD.lib;debug;C:/Users/Trawick/OpenSSL-Win64
/lib/VC/libeay32MDd.lib (found version "1.0.2")
...
Interestingly, the version of the old binary install of OpenSSL is 1.0.1e,
whereas the version of my build is 1.0.2 (pre-release). FindOpenSSL thinks
it has 1.0.2 but points to the old libraries.
To filter out the obvious suggestion of uninstalling the old binary, I'm
trying to document how to make this work as expected for an arbitrary set
of users of Apache HTTP Server (httpd) on Windows, who might just need to
quickly build a new OpenSSL version and be sure that it is used, regardless
of what they or some product install may have done months or years earlier.
("Heartbleed" anyone?) Here is my current warning to users, should they
read it:
http://svn.apache.org/viewvc/httpd/httpd/trunk/README.cmake?r1=1541922&r2=1583027&diff_format=h
(But I think the real problem is the registry entry created by the old
binary install, not the "well-known" location.)
The httpd cmake list would not seem to be at fault here (see
http://svn.apache.org/viewvc/httpd/httpd/trunk/CMakeLists.txt?view=markup),
though I'd be thrilled if it was and could fix it.
The issue is clearly related to FindOpenSSL's preference for libraries with
"MD", "MDd", "MT", "MTd", or other such suffixes, which are not created by
a normal OpenSSL build. Somehow it is willing to bypass OPENSSL_ROOT_DIR
to find them.
It isn't clear to me why FindOpenSSL would care about the binary build if
OPENSSL_ROOT_DIR has been set:
if (WIN32)
# http://www.slproweb.com/products/Win32OpenSSL.html
set(_OPENSSL_ROOT_HINTS
${OPENSSL_ROOT_DIR}
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL
(32-bit)_is1;Inno Setup: App Path]"
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL
(64-bit)_is1;Inno Setup: App Path]"
ENV OPENSSL_ROOT_DIR
)
(and still other locations in the search path, most of which seem to be
possible locations where somebody installed one of those binary installers
from slproweb.com)
I don't think there's anything I can set on the cmake command-line to
circumvent this (any suggestions?).
I'd love to see a intuitive solution along the lines of setting a variable
respected by FindOpenSSL to the root install dir and it then ignores
everything else.
(Thanks to casey goodlett for walking me through FindOpenSSL after I
ambushed him at a user group meeting last night!)
Suggestions?
TIA!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
http://edjective.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140515/e7de8c4e/attachment.html>
More information about the CMake
mailing list