openssl build failure on mingw #12919
Comments
ashishvarman
changed the title
|
We have found no issues at all building it from source on MinGW!
Perhaps your environment is 'polluted' somehow! Have you tried some other alternatives? |
|
It is heartening to know that the problem is most probably isolated to my environment as well and not the package or build system. |
|
just tried on an msys2 mingw installation - same error |
|
I build large projects from source on a regular basis without issues! Have fun. |
|
I am using MinGW - that bundled with Qt. I have also tried MSYS2. Should I use any other? My prime need for using vcpkg is the richer set of libraries that are much easier to use - e.g. sqlite-modern-cpp or sqlitecpp instead of using sqlite3 directly and cpr instead of curl and openssl directly. If nothing works out, most probably I will make a separate python exe that will take a url and save to file and read from that. Though it still seems odd that a simple task such as https retrieval is so difficult for me on C++ - on which I have been working for more than 10 years and a simple 2 liner in python - on which I have started since 2 years 😐 Perhaps leaving MSVC for MinGW was not such a great idea after all. |
|
If you lack the skills to build simple projects from source, you can download binaries from different sources. |
|
You mentioned MinGW (Qt) and MSYS2. Can you post here the errors you are getting while using MinGW and MSYS2? |
|
The errors are identical to the first I posted. Only the path of the tools being used differs in the log file according to the toolchain being used. I am attaching the MSYS2 log file. install-x64-mingw-dynamic-dbg-out.msys64.log Just saw that according to log message by @cristianadam , STL's mingw distro is being used to test x64-mingw makefiles. Will try that as well and report the result. |
|
Perhaps I wasn't clear (enough)! a) Configure ....... Example:
Cheers. |
|
Sorry for not understanding what you required and thanks once again for helping me. Unfortunately, MinGW bundled with Qt doesn't have perl which is required for
Thanks for bearing with me once again. |
|
I am getting frustated with your current situation since nothing seems to work properly on your end! I took me 2 mins to build OpenSSL 1.1.1g from source without installing a single app or tool. Please, advise how to proceed. Cheers. |
Believe me - I am frustrated as well.
My employer makes engineering GUI software on windows using Visual C++. I have fought for years for migrating from Microsoft / MFC and finally Qt with MinGW gave us the results we wanted as well as satisfying all the legal and corporate requirements. Also, we had to select a toolchain and design a workflow that is easy for developers since attracting talent is next to impossible in a tier 2 town in India and we have to make do with what we get.
You are correct. However, Qt + MinGW has served our purpose till now of making C++ GUI applications on Windows.
I wish - then I would have just gone to my seniors with my problem. As of now, it is up to me to find a solution to easily retrieve http content in C++ which should be simple enough that our developers can use it without messing it up. I have explored curl, boost::asio and boost::beast and cpr seems to be much much easier than any of them. In any case, openssl is a requirement for all of them for HTTPS. We were using vcpkg for using libraries in visual studio and it carried over when we moved to Qt. Some libs that were either not available (talib) or not buildable (boost) in vcpkg with the Qt + MinGW toolchain, we manged to build ourselves.
I think that currently the best course for me to get the work moving again is to just make a python exe and call it from C++. Later, when I can get openssl to build or integrate its binaries, I will try to come back to using cpr again. If I get the time, I will also try with STL's MinGW distro. If the vcpkg maintainers have tested x64 builds with it then I have high hopes of it working.
Thanks and Regards |
|
Qt Installer comes with MinGW and Perl (Strawberry Perl), as perl is required to build Qt itself. The MinGW shipped with Qt Installer (GCC 7.3, or the latest 8.1) should be sufficient to build OpenSSL using vcpkg. It is not sufficient to build vcpkg itself. |
|
I decided to give it a try.
I would expect the recipe that vcpkg has to see that it has perl and then it should simply compile OpenSSL with its perl build system. But instead it downloaded msys2 and what not, and in the end if failed miserably: Then for the fun of it I tried building zlib, which worked a few weeks ago: No idea why vcpkg zlib recipe is trying to use vcpkg support with MinGW (not MSYS2) is experimental and its recipe quality is getting worse. |
|
Actually it's OpenSSL which is wrong here. It assumes MinGW is always MSYS2. This explains why vcpkg is trying to use msys2. I tried changing I'll add a comment at openssl/openssl#10902 |
|
I see that @longnguyen2004 made a fix #12089 to issue #9749 but later deleted his branch because of some mess up. Hopefully, when #9749 is fixed then this will be too. |
Unfortunately, it seems that the online installer does not install perl and installs the pre-built Qt binaries directly. I couldn't find anything named perl in my C:\Qt directory nor anywhere else in my system. I also didn't find any mention of perl in the Qt Maintenance Tool Also, I see an openssl entry at the bottom of the list. Let me install that and see if I am able to build CPR using it.
Right. I have VS2019 installed and that is used to build vcpkg by the bootstrap-vcpkg.bat script. |
|
I've made another PR #12544 and it has passed long ago. Maybe this is another problem, since I regularly tests with |
|
And yes I'm also very frustrated with openssl's build system being completely dependent on MSYS2 perl, which is the main show stopper in my effort moving away from MSYS2. I've tried patching the build system but then it writes unescaped backslashes into the Makefiles and sources... |
|
For other maintainers: |
|
Please test #12986 |
|
https://github.com/janbar/openssl-cmake/ is a thing. I don't know if it's being packaged by vcpkg. |
|
Using the PR #12986 by @longnguyen2004 I was able to successfully build openssl as well as curl and cpr. It does still pull in msys2 which was perhaps expected. I suppose I have to wait till this PR is merged before marking this as closed? P.S. I suppose now all of boost should also build. I have built boost separately from vcpkg till now. |
|
I guess we'll have to wait for the update to boost 1.74, which fixes a few problems with mingw compilers in |
|
Thanks everybody for the great help. Thanks @cristianadam for confirming that the problem is not with just me. And thanks @longnguyen2004 for the quick fix. |
Host Environment
To Reproduce
Steps to reproduce the behavior:
./vcpkg install openssl:x64-mingw-dynamicFailure logs
E:\vcpkg-orig>vcpkg install openssl:x64-mingw-dynamic
Your feedback is important to improve Vcpkg! Please take 3 minutes to complete our survey by running: vcpkg contact --survey
Computing installation plan...
The following packages will be built and installed:
openssl[core]:x64-mingw-dynamic
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-mingw-dynamic...
Starting package 1/2: openssl-unix:x64-mingw-dynamic
Building package openssl-unix[core]:x64-mingw-dynamic...
Could not locate cached archive: C:\Users\ashish.varman\AppData\Local\vcpkg\archives\2f\2fa3d0eddad98e88cdd65d1a83b585b2af0e2696.zip
-- Using community triplet x64-mingw-dynamic. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: E:\vcpkg-orig\triplets\community\x64-mingw-dynamic.cmake
-- Using cached E:/vcpkg-orig/downloads/openssl-1.1.1g.tar.gz
-- Cleaning sources at E:/vcpkg-orig/buildtrees/openssl-unix/src/1.1.1g-bb2a9a5801.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source E:/vcpkg-orig/downloads/openssl-1.1.1g.tar.gz
-- Using source at E:/vcpkg-orig/buildtrees/openssl-unix/src/1.1.1g-bb2a9a5801.clean
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Configuring x64-mingw-dynamic
-- Building x64-mingw-dynamic-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:139 (message):
Command failed: E:/vcpkg-orig/downloads/tools/cmake-3.17.2-windows/cmake-3.17.2-win32-x86/bin/cmake.exe --build . --config Debug --target install -- -v
Working Directory: E:/vcpkg-orig/buildtrees/openssl-unix/x64-mingw-dynamic-dbg
See logs for more information:
E:\vcpkg-orig\buildtrees\openssl-unix\install-x64-mingw-dynamic-dbg-out.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_build_cmake.cmake:91 (vcpkg_execute_build_process)
scripts/cmake/vcpkg_install_cmake.cmake:24 (vcpkg_build_cmake)
ports/openssl-unix/portfile.cmake:51 (vcpkg_install_cmake)
scripts/ports.cmake:79 (include)
Error: Building package openssl-unix:x64-mingw-dynamic failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with
.\vcpkg update, thensubmit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: openssl-unix:x64-mingw-dynamic
Vcpkg version: 2020.06.15-nohash
Additionally, attach any relevant sections from the log files above.
install-x64-mingw-dynamic-dbg-out.log
Additional context
Trying to use cpr for http retrieval in a private library for use in a qt project. Private library doesn't use qt. I suppose this issue (dependency on openssl) will be there regardless of which http library is used. Cannot use MSVC because an ActiveX GUI component (TeeChart) being used in the final project doesn't generate usable interface for Qt-MSVC.
The text was updated successfully, but these errors were encountered: