You are not logged in.
Hi!
This morning an issue was opened on my github project about the Windows binaries not working, I went to investigate and found that building mingw-w64-openssl on an updated system does not currently result in a working (static) library.
Since building the previous version of mingw-w64-openssl showed the same problems (even though it worked before), I went on to investigate its dependencies. Long story short, what I found was:
On a fully updated system, with mingw-w64-binutils 2.43-1, building mingw-w64-openssl results in:
$ ls -lh /usr/x86_64-w64-mingw32/lib/libcrypto.dll.a
-rwxr-xr-x 1 root root 115M feb 15 14:57 /usr/x86_64-w64-mingw32/lib/libcrypto.dll.a
Note the abnormally large archive of 115M. Building and installing the openssl package shows no errors. Building any small example program using openssl results in a very large executable, that fails to run:
[~/programming/tests/openssl_tests] $ cat OPENSSL_AES_ENCRYPTION.cc
#include <memory>
#include <iostream>
#include <openssl/evp.h>
int main()
{
std::cout << "OpenSSL version: " << OPENSSL_VERSION_TEXT << std::endl;
std::unique_ptr<EVP_CIPHER_CTX, decltype(&::EVP_CIPHER_CTX_free)> ctx(EVP_CIPHER_CTX_new(), &::EVP_CIPHER_CTX_free);
EVP_CIPHER_CTX_set_padding(ctx.get(), 0);
std::cout << "Done" << std::endl;
return 0;
}
[~/programming/tests/openssl_tests] $ x86_64-w64-mingw32-g++ -Wall -Wextra -Woverloaded-virtual -Wshadow -c -pedantic -std=c++23 -D_WIN32_WINNT=0x600 -I/usr/x86_64-w64-mingw32/include/ -O3 -flto -o openssl_test.exe OPENSSL_AES_ENCRYPTION.cc
[~/programming/tests/openssl_tests] $ ls -lh openssl_test.exe
-rw-r--r-- 1 svandijk svandijk 19M feb 15 15:37 openssl_test.exe
Running the resulting binary on Windows shows no output at all.
After _only_ downgrading mingw-w64-binutils to the previous version 2.39-1 (pacman -U mingw-w64-binutils-2.39-1-x86_64.pkg.tar.zst), building mingw-w64-openssl gives:
$ ls -lh /usr/x86_64-w64-mingw32/lib/libcrypto.dll.a
-rwxr-xr-x 1 root root 3,7M feb 15 15:06 /usr/x86_64-w64-mingw32/lib/libcrypto.dll.a
The library size is back to normal. Compiling the same small test program now is also much smaller:
[~/programming/tests/openssl_tests] $ x86_64-w64-mingw32-g++ -Wall -Wextra -Woverloaded-virtual -Wshadow -c -pedantic -std=c++23 -D_WIN32_WINNT=0x600 -I/usr/x86_64-w64-mingw32/include/ -O3 -flto -o openssl_test.exe OPENSSL_AES_ENCRYPTION.cc
[~/programming/tests/openssl_tests] $ ls -lh openssl_test.exe
-rw-r--r-- 1 svandijk svandijk 19K feb 15 15:37 openssl_test.exe
And it runs on Windows just fine:
C:\Users\User>S:\openssl_test.exe
OpenSSL version: OpenSSL 3.4.1 11 Feb 2025
Done
C:\Users\User>
I guess I don't have a question really, apart from: can anyone confirm these findings, or am I doing something stupid? Does anyone happen to have more info on this?
Thanks!
Offline
There's a newer version (2.44) of mingw-w64-binutils in extra-testing , have you tried with that one ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
There's a newer version (2.44) of mingw-w64-binutils in extra-testing , have you tried with that one ?
Thanks for the suggestion. Unfortunately, 2.44 gives the same result as 2.43.
*edit*
Though they were never packaged, I have also built some of the previous versions, and can say that 2.43 is the first version showing this problem, any earlier works.
Last edited by bepaald (2025-02-16 14:56:09)
Offline