<div dir="ltr"><div>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.)</div><div>
<br></div>Some info about my build environment:<div><br></div><div>* pristine install of cmake 2.8.12.2-win32-x86</div><div>* "Open VS2012 x64 Native Tools Command Prompt"</div><div>* previously installed OpenSSL 1.0.1e via Win64 installer from <a href="http://slproweb.com/products/Win32OpenSSL.html">http://slproweb.com/products/Win32OpenSSL.html</a>; installed to %HOME%\OpenSSL-Win64, and apparently in registry</div>
<div>* 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"</div>
<div><br></div><div>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:</div><div><br></div><div><div>mkdir C:\Users\Trawick\BUILDDIRS\251\httpd</div>
<div>cd C:\Users\Trawick\BUILDDIRS\251\httpd && cmake -DCMAKE_INSTALL_PREFIX=C:\Users</div><div>\Trawick\PREFIXES\251 -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=RelWithDebInfo -DO</div><div>PENSSL_ROOT_DIR=C:\Users\Trawick\PREFIXES\251 -DENABLE_MODULES=a -DINSTALL_MANUA</div>
<div>L=OFF  C:\Users\Trawick/svn/httpd</div><div>-- The C compiler identification is MSVC 17.0.61030.0</div><div>-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio</div><div>11.0/VC/bin/amd64/cl.exe</div>
<div>-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio</div><div>11.0/VC/bin/amd64/cl.exe -- works</div><div>-- Detecting C compiler ABI info</div><div>-- Detecting C compiler ABI info - done</div>
<div>-- Found LibXml2: C:/Users/Trawick/PREFIXES/251/lib/libxml2.lib (found version "</div><div>2.9.1")</div><div>-- Found Lua51: C:/Users/Trawick/PREFIXES/251/lib/lua5.1.lib (found version "5.1</div><div>.5")</div>
<div>-- Found OpenSSL: optimized;C:/Users/Trawick/OpenSSL-Win64/lib/VC/ssleay32MD.lib</div><div>;debug;C:/Users/Trawick/OpenSSL-Win64/lib/VC/ssleay32MDd.lib;optimized;C:/Users/</div><div>Trawick/OpenSSL-Win64/lib/VC/libeay32MD.lib;debug;C:/Users/Trawick/OpenSSL-Win64</div>
<div>/lib/VC/libeay32MDd.lib (found version "1.0.2")</div></div><div>...</div><div><br></div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div><a href="http://svn.apache.org/viewvc/httpd/httpd/trunk/README.cmake?r1=1541922&r2=1583027&diff_format=h">http://svn.apache.org/viewvc/httpd/httpd/trunk/README.cmake?r1=1541922&r2=1583027&diff_format=h</a><br>
</div><div><br></div><div>(But I think the real problem is the registry entry created by the old binary install, not the "well-known" location.)</div><div><br></div><div>The httpd cmake list would not seem to be at fault here (see <a href="http://svn.apache.org/viewvc/httpd/httpd/trunk/CMakeLists.txt?view=markup">http://svn.apache.org/viewvc/httpd/httpd/trunk/CMakeLists.txt?view=markup</a>), though I'd be thrilled if it was and could fix it.</div>
<div><br></div><div>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.</div>
<div><br></div><div>It isn't clear to me why FindOpenSSL would care about the binary build if OPENSSL_ROOT_DIR has been set:</div><div><br></div><div><div>if (WIN32)</div><div>  # <a href="http://www.slproweb.com/products/Win32OpenSSL.html">http://www.slproweb.com/products/Win32OpenSSL.html</a></div>
<div>  set(_OPENSSL_ROOT_HINTS</div><div>    ${OPENSSL_ROOT_DIR}</div><div>    "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (32-bit)_is1;Inno Setup: App Path]"</div><div>
    "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (64-bit)_is1;Inno Setup: App Path]"</div><div>    ENV OPENSSL_ROOT_DIR</div><div>    )</div><div>    (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 <a href="http://slproweb.com">slproweb.com</a>)</div>
<div><br></div><div>I don't think there's anything I can set on the cmake command-line to circumvent this (any suggestions?).</div><div><br></div><div>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.</div>
<div><br></div><div>(Thanks to casey goodlett for walking me through FindOpenSSL after I ambushed him at a user group meeting last night!)</div><div><br></div><div>Suggestions?</div><div><br></div><div>TIA!</div>-- <br><div dir="ltr">
Born in Roswell... married an alien...<br><a href="http://emptyhammock.com/" target="_blank">http://emptyhammock.com/</a><br><div><a href="http://edjective.org/" target="_blank">http://edjective.org/</a></div><div><br></div>
</div>
</div></div>