Arch Linux User Repository

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

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

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.

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

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

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.

@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.

@Martchus Yeah, absolutely. I created a tiny sample project here: https://github.com/chenxiaolong/mingw_openssl_test 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: https://gist.github.com/chenxiaolong/94c4603c5f8f763b820bfa2ee3f335d4 In CMakeCache.txt, it has: LIB_EAY:FILEPATH=/usr/i686-w64-mingw32/bin/libeay32.dll SSL_EAY:FILEPATH=/usr/i686-w64-mingw32/bin/ssleay32.dll

@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).

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