MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015071CMakeCMakepublic2014-08-08 11:472015-03-02 08:57
ReporterFrank Benkstein 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0015071: building cmake on Windows against statically compiled openssl puts dlls into bin directory
DescriptionI am building a custom version of cmake 3.0.1 with 32bit Visual Studio 2010 on 64bit Windows 7. In my build script I build openssl statically and then build cmake with an installed version 3.0.0.

It seems that cmake builds and links correctly agaist my own openssl. Unfortunately, the libea32.dll and ssleay32.dll from the locally installed cmake are also picked up and put into the install prefix.

I tracked this down to these rules in my ninja file:

# =============================================================================
# Write statements declared in CMakeLists.txt:
# C:/Users/Frank/Projects/custom-cmake/cmake/src/Utilities/cmcurl/CMakeLists.txt
# =============================================================================

<-- snip -->

#############################################
# Custom command for bin\.\libeay32.dll

build bin\.\libeay32.dll: CUSTOM_COMMAND C$:\usr\CMake-3.0.0\bin\libeay32.dll || Utilities\cmzlib\cmzlib.lib
  COMMAND = cmd.exe /C "cd /D C:\Users\Frank\Projects\custom-cmake\cmake\gen\cmake-build\Utilities\cmcurl && C:\usr\CMake-3.0.0\bin\cmake.exe -E copy C:/usr/CMake-3.0.0/bin/libeay32.dll C:/Users/Frank/Projects/custom-cmake/cmake/gen/cmake-build/bin/./libeay32.dll"
  DESC = Generating ../../bin/./libeay32.dll

#############################################
# Custom command for bin\.\ssleay32.dll

build bin\.\ssleay32.dll: CUSTOM_COMMAND C$:\usr\CMake-3.0.0\bin\ssleay32.dll || Utilities\cmzlib\cmzlib.lib
  COMMAND = cmd.exe /C "cd /D C:\Users\Frank\Projects\custom-cmake\cmake\gen\cmake-build\Utilities\cmcurl && C:\usr\CMake-3.0.0\bin\cmake.exe -E copy C:/usr/CMake-3.0.0/bin/ssleay32.dll C:/Users/Frank/Projects/custom-cmake/cmake/gen/cmake-build/bin/./ssleay32.dll"
  DESC = Generating ../../bin/./ssleay32.dll

I found the responsible code block in Utilities/cmcurl/CMakeLists.txt but I have no idea how to fix it myself.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2014-08-08 11:47Frank BenksteinNew Issue
2014-08-11 10:07Brad KingNote Added: 0036589
2014-08-28 05:11Frank BenksteinNote Added: 0036686
2014-08-28 09:04Brad KingNote Added: 0036687
2014-09-17 05:27Frank BenksteinNote Added: 0036818
2014-09-18 08:48Brad KingStatusnew => resolved
2014-09-18 08:48Brad KingResolutionopen => no change required
2015-03-02 08:57Robert MaynardNote Added: 0038125
2015-03-02 08:57Robert MaynardStatusresolved => closed

Notes
(0036589)
Brad King   
2014-08-11 10:07   
Try adding -DCMAKE_EAY_DLL= -DCMAKE_SSL_DLL= to tell those find_file calls not to search. Then the following IF(CMAKE_SSL_DLL AND CMAKE_EAY_DLL) block will not run.
(0036686)
Frank Benkstein   
2014-08-28 05:11   
Hello, Brad.

this fixes the issue for me. It would still be nice if CMake could detect if the OpenSSL it links against is compiled statically. It seems to be that the information is already there because it picks up the libs correctly during the link stage.

Regards,
Frank.
(0036687)
Brad King   
2014-08-28 09:04   
Re 0015071:0036686: CMake doesn't know whether the .lib you choose is a static library or an import library for a dll. It doesn't need to know this to link to it. The exact purpose of CMAKE_EAY_DLL and CMAKE_SSL_DLL is to tell CMake about the runtime dependencies of the library chosen.
(0036818)
Frank Benkstein   
2014-09-17 05:27   
Okay, I think this can be closed.
(0038125)
Robert Maynard   
2015-03-02 08:57   
Closing resolved issues that have not been updated in more than 4 months.