MantisBT - CMake
View Issue Details
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")
Additional Information
TagsNo tags attached.
Relationships
related to 0015370closed Brad King find_path, find_file, and find_library should get prefixes from PATH 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-02-18 03:52David DemelierNew Issue
2015-02-18 09:33Brad KingNote Added: 0037992
2015-02-19 09:47Brad KingNote Added: 0038001
2015-02-19 09:47Brad KingRelationship addedrelated to 0015370
2015-02-19 09:49Brad KingNote Added: 0038002
2015-02-19 09:49Brad KingAssigned To => Brad King
2015-02-19 09:49Brad KingStatusnew => resolved
2015-02-19 09:49Brad KingResolutionopen => fixed
2015-02-19 09:49Brad KingFixed in Version => CMake 3.3
2015-02-19 09:49Brad KingTarget Version => CMake 3.3
2015-06-05 18:15Tony KelmanNote Added: 0038887
2015-06-05 18:22Tony KelmanNote Edited: 0038887bug_revision_view_page.php?bugnote_id=38887#r1800
2015-06-08 10:22Brad KingNote Added: 0038893
2015-06-08 10:43Tony KelmanNote Added: 0038896
2016-01-04 11:51Robert MaynardNote Added: 0040063
2016-01-04 11:51Robert MaynardStatusresolved => closed

Notes
(0037992)
Brad King   
2015-02-18 09:33   
Where are the proper libraries located that you expect to be found?
(0038001)
Brad King   
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   
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   
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   
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   
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   
2016-01-04 11:51   
Closing resolved issues that have not been updated in more than 4 months.