View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015409CMakeModulespublic2015-02-18 03:522016-01-04 11:51
ReporterDavid Demelier 
Assigned ToBrad King 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSWindows 7OS Version
Product VersionCMake 3.1 
Target VersionCMake 3.3Fixed in VersionCMake 3.3 
Summary0015409: FindOpenSSL does not find correct libraries with MinGW
DescriptionWhen using MinGW Generator, FindOpenSSL locate the following DLL as OPENSSL_LIBRARIES:

C:\Program Files (x86)\CMake\bin\libeay32.dll
C:\Program Files (x86)\CMake\bin\ssleay32.dll

It indeed makes ld.exe crash since these are not import libraries. And OpenSSL built with mingw are named libssl.dll.a and libcrypto.dll.a.
Steps To ReproduceUse find_package(OpenSSL) with MinGW Generator.

Ends with:

-- Found OpenSSL: C:/Program Files (x86)/CMake/bin/ssleay32.dll;C:/Program Files (x86)/CMake/bin/libeay32.dll (found version "1.0.1h")
TagsNo tags attached.
Attached Files

 Relationships
related to 0015370closedBrad King find_path, find_file, and find_library should get prefixes from PATH 

  Notes
(0037992)
Brad King (manager)
2015-02-18 09:33

 Where are the proper libraries located that you expect to be found?
(0038001)
Brad King (manager)
2015-02-19 09:47

 This issue revealed three problems. First, find_library should not consider ".dll" files to be linkable. I think at one time linkable .dll files may have been used with MinGW tools but it is not common anymore AFAIK:

 Windows-GNU: Do not tell find_library to treat '.dll' as linkable
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a0f17fbe [^]

Second, CMake 3.2 is supposed to use the native TLS/SSL APIs on Windows and OS X and not need to be built against or come with OpenSSL DLLs anymore. The source has the logic for this but for the 3.2.0-rc1 builds we forgot to update the scripts to not build against OpenSSL on those platforms. Now done:

 Utilities/Release: Build OS X and Win binaries without OpenSSL
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e6608fe [^]

Third, the find_library and similar commands should be able to search the MinGW installation prefix automatically when its 'bin' directory is in the PATH. This is discussed in issue 0015370.
(0038002)
Brad King (manager)
2015-02-19 09:49

 The first change mentioned in 0015409:0038001 to not consider ".dll" files to be libraries is the main fix for this issue, and will be targeted for release 3.3.
(0038887)
Tony Kelman (reporter)
2015-06-05 18:15
edited on: 2015-06-05 18:22

 > First, find_library should not consider ".dll" files to be linkable. I think at one time linkable .dll files may have been used with MinGW tools but it is not common anymore AFAIK:

This is a huge mistake. Please reconsider this. This will make cmake unusable with MinGW for quite a few projects. The .dll.a files are not universally generated by all other projects' build systems (the commit message "Modern software distributions always use a separate ".dll.a" or ".lib" import library for linking." is demonstrably false), and are not required to link to a dll with MinGW. Linking against a .dll without a .dll.a works and is valid. I feel "makes ld.exe crash" needs a lot more elaboration here before making a big breaking change that will prevent find_library from working in quite a few cases.
(0038893)
Brad King (manager)
2015-06-08 10:22

 Re 0015409:0038887: Thanks. I'm not surprised some projects still need this. I've reverted the change:

 Windows-GNU: Restore find_library treatment of '.dll' as linkable
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f5dbf00d [^]

and have scheduled this fix for 3.3.0-rc2.

The other two parts enumerated in 0015409:0038001 are not affected by this anyway so the issue originally reported here remains resolved.
(0038896)
Tony Kelman (reporter)
2015-06-08 10:43

 Thank you tremendously Brad. While more projects will gradually see the light and convert from hand-rolled build systems to something sane and standardized like CMake, it's not 100% there yet. For now this will help projects that are using CMake to depend on those existing libraries without also needing to rewrite dependencies' build systems in the process.
(0040063)
Robert Maynard (manager)
2016-01-04 11:51

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2015-02-18 03:52 David Demelier New Issue
2015-02-18 09:33 Brad King Note Added: 0037992
2015-02-19 09:47 Brad King Note Added: 0038001
2015-02-19 09:47 Brad King Relationship added related to 0015370
2015-02-19 09:49 Brad King Note Added: 0038002
2015-02-19 09:49 Brad King Assigned To => Brad King
2015-02-19 09:49 Brad King Status new => resolved
2015-02-19 09:49 Brad King Resolution open => fixed
2015-02-19 09:49 Brad King Fixed in Version => CMake 3.3
2015-02-19 09:49 Brad King Target Version => CMake 3.3
2015-06-05 18:15 Tony Kelman Note Added: 0038887
2015-06-05 18:22 Tony Kelman Note Edited: 0038887
2015-06-08 10:22 Brad King Note Added: 0038893
2015-06-08 10:43 Tony Kelman Note Added: 0038896
2016-01-04 11:51 Robert Maynard Note Added: 0040063
2016-01-04 11:51 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team