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

Git Clone URL: (read-only, click to copy)
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.000000
First Submitted: 2017-06-05 01:00
Last Updated: 2020-01-30 12:52

Latest Comments

1 2 Next › Last »

Martchus commented on 2020-05-18 14:15

@drakkan Thanks. I'll keep the package nevertheless around for some time. Maybe somebody is still using it directly.

drakkan commented on 2020-05-18 13:03

Hi, I removed this dependency from mingw-w64-librtmp0 so no PKGBUILD still depends on this old openssl version, maybe this package could be removed

Martchus commented on 2019-09-25 14:36

The DLLs are packaged. They are still called libeay32.dll and ssleay32.dll in the 1.0 version. This has also been in accordance with Qt's runtime lookup for these DLLs (at the time the legacy version was still used by Qt). So I guess these names are correct.

xantares commented on 2019-09-25 13:34

why didnt you package the dlls ? (libssl.dll & libcrypto.dll)

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