Package Details: mingw-w64-openssl-1.0 1.0.2.s-1

Git Clone URL: (read-only)
Package Base: mingw-w64-openssl-1.0
Description: The Open Source toolkit for Secure Sockets Layer and Transport Layer Security
Upstream URL:
Licenses: custom:BSD
Submitter: Martchus
Maintainer: Martchus
Last Packager: Martchus
Votes: 2
Popularity: 0.000725
First Submitted: 2017-06-05 01:00
Last Updated: 2019-06-27 10:24

Latest Comments

Schala commented on 2017-07-29 05:44

instead of `make install` do `make install_sw` to avoid installing all those man pages

Martchus commented on 2017-06-11 20:12

Another option would be providing a symlink libcrypto.dll to libcrypto-1_1.dll. This would be a very simple solution. However, I think that symlink should be in mingw-w64-openssl then.

Martchus commented on 2017-06-11 19:45

@chenxiaolong I can reproduce now. On the system I tested mingw-w64-openssl-1.0 was installed but the DLLs were missing. This likely happened due to upgrading mingw-w64-openssl from 1.0 to 1.1 and installing mingw-w64-openssl-1.0 at the same time.

CMake looks for DLL suffixes in the following order (value of CMAKE_FIND_LIBRARY_SUFFIXES): .dll .dll.a .a .lib

Here the library name is crypto or eay32 so the search order becomes: libcrypto.dll, libeay32.dll, libcrypto.dll.a, libeay32.dll.a, ...

Unfortunately libcrypto.dll doesn't exist (because the lib is actually called libcrypto-1_1.dll) so you end up getting libeay32.dll. I find it kind of strange that CMake prefers .dll over .dll.a because as far as I know using import libraries is the preferred way of linking under Windows, right? Changing the order to prefer import libs would solve this problem (adding `set(CMAKE_FIND_LIBRARY_SUFFIXES .dll.a;.lib;.a)` after `project(...)`).

But I can also move the libs to another directory as a workaround. This would have the disadvantage that Qt and qca will not be able to find the libs by default.

chenxiaolong commented on 2017-06-11 17:09

@Martchus Yeah, absolutely. I created a tiny sample project here: I explicitly called OPENSSL_init_crypto (added in openssl 1.1.0) so it wouldn't compile if cmake tried to link it to openssl-1.0.

If I do a build with a clean environment, it finds libeay32.dll instead of libcrypto.dll.a:

$ mkdir build && cd build
$ env -i PATH="/usr/local/sbin:/usr/local/bin:/usr/bin" i686-w64-mingw32-cmake ..

Results in the following:

In CMakeCache.txt, it has:


Martchus commented on 2017-06-11 14:26

@chenxiaolong Can you provide steps to reproduce? I tried

`echo 'find_package(OpenSSL)' > CMakeLists.txt && x86_64-w64-mingw32-cmake`

and got: `Found OpenSSL: /usr/x86_64-w64-mingw32/lib/libcrypto.dll.a (found version "1.1.0f")`

Also `cat CMakeCache.txt | grep 'EAY:FILEPATH'` prints correct paths. And it works with i686 and `set(OPENSSL_USE_STATIC_LIBS ON)`, too.

That you get the actual library instead of the import library looks like a CMake bug (which I can not reproduce here).

xantares commented on 2017-06-11 11:33

I see,
bin/libeay32.dll is part of mingw-w64-openssl-1.0

chenxiaolong commented on 2017-06-11 04:31

@Martchus Any chance you could revert this commit?

It's causing CMake to find openssl-1.0 instead of openssl for me. I realize this is probably a cmake bug, but for example, before I installed this package, I would get:

-- Found OpenSSL: /usr/i686-w64-mingw32/lib/libssl.dll.a (found version "1.1.0f")

and now it is:

-- Found OpenSSL: /usr/i686-w64-mingw32/bin/libeay32.dll (found version "1.1.0f")

xantares commented on 2017-06-09 19:24

hi, are you getting these?

==> Validating source files with sha256sums...
openssl-1.0.2l.tar.gz ... FAILED
openssl-1.0.2l.tar.gz.asc ... Skipped
openssl-1.0.2a-x509.patch ... FAILED
openssl-1.0.0a-ldflags.patch ... FAILED
openssl-1.0.1-x32.patch ... FAILED
openssl-1.0.2a-parallel-build.patch ... FAILED
openssl-1.0-versioned-symbols.patch ... Passed
==> ERROR: One or more files did not pass the validity check!