I am trying to build and link OpenSSL on Windows 8 and I've found it really daunting. I should mention that I am aware of following posts
OpenSSL Windows x64 Compilation error
How do you compile OpenSSL for x64?
Building OpenSSL VC++ Static 64bit Libs
but none of them addressed what I do really need to know. Therefore I decided to share my experience with you guys as a new post!
First, I can successfully build and link OpenSSL on a Win32 OS and it perfectly works. I know that Windows 8 comes with WOW64. “WOW64 is an x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows”, though when I run my app that is built on windows 7 32-bit, I receive an error “The program can’t start because libeay32.dll is missing from your computer…” while “libeay32.dll” is apparently there and not missing.
In order to avoid registry missing stuffs, I tried to build OpenSSL in 32bit mode on Windows 8. The build was successfully done and the app linked correctly with no error. Again when I run the app I received the same error message.
And then I tried to build it in 64bit mode based on the following steps;
set PATH=%PATH%;c:\perl\bin;c:\nasm;
call "c:\visual studio\2012\vc\vcvarsall.bat" x64
perl Configure VC-WIN64A no-shared no-idea
call ms\do_win64a
copy ms\libeay32.def ms\libeay64.def /Y
copy ms\ssleay32.def ms\ssleay64.def /Y
ssed -e s/out32/out64/g ms\ntdll.mak | ssed … > ms\ntdll-64.mak
ssed -e s/out32/out64/g ms\nt.mak | ssed … > ms\nt-64.mak
nmake -f ms\ntdll-64.mak
nmake -f ms\ntdll-64.mak test
nmake -f ms\ntdll-64.mak install
In this case, I received a lot of warnings mostly on “data conversion and possibility of data loss” during build but it was built and while “test” failed “install” generated outputs.
Now when I try to build my solution in Visual Studio using new “libeay64.lib and ssleay64.lib” I receive almost thousands of errors saying “unresolved external symbol”
So if possible please answer following questions;
Why I cannot run my 32bit app on Windows 8 (64bit)?
Why correctly built OpenSSL (32bit mode) on Windows 8, still
encounters same error?
In OpenSSL build (64bit mode), am I making something wrong?
I am using OpenSSL ver 1.0.1e, Visual Studio 2012 and nasm 2.10.07
Thanks
I am partially answering your question:
You can run 32-bit under 64-bit in WOW64.
For OpenSSL under 64-bit, there is a compiler option /WX under visual studio which means treat warnings as an error. Remove that compiler option from the makefile. You will get lots of warnings. But OpenSSL will get compiled.
Since, most of the modules are not compiled and their object file is not generated, that is why you are getting linker error. Please let me know if it solves your problem.
Related
I have followed same step mentioned in this question. Few extra flag I have set get propriety FFMPEG codec. Its failing every time, with following logs.
[233/19712] ACTION Copying D3D Compiler DLL...
FAILED: F:\Chrome\depot_tools\python276_bin\python.exe gyp-win-tool action-wrapper environment.x86 copy_compiler_dll_target_copy_dll_a30e198148542d4bce19a5c818c6884f..rsp ..\..\third_party\angle\src
[233/19712] CC obj\third_party\icu\source\stubdata\icuuc.stubdata.obj
ninja: build stopped: subcommand failed.
For FFMPEG using following set command:
set GYP_DEFINES=branding=Chromium buildtype=Official component=shared_library disable_nacl=1 enable_automation=0 enable_captive_portal_detection=0 enable_google_now=0 enable_hidpi=0 fastbuild=1 ffmpeg_branding=Chrome incremental_chrome_dll=0 proprietary_codecs=1 remoting=0
My System Information Details:
Windows 10 64 Bit 8 GB RAM. Trail Version of Visual Studio 2015
Installed, but now it is expired. Now I have installed Community
Version 2013 update 4.
Does it effect both version effect the execution? Checked in path, its using Window Kit 8.1. What other part should I check for successful execution?
You need to install Win10 SDK. That did it for me.
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=13945#p29872
LE: However, later on in the build you may find all sorts of not found headers and/or other compile errors. This is most likely due to installing Win 10 SDK after having first fired the build\gyp_chromium.py command and realizing that it had not worked. What you need to do in order to move on is delete all the precompiled headers generated in your target output (eg. out\Debug) and then rerun the build\gyp_chromium.py and ninja -C ... commands.
I have picked this up from Daniel Bratell's answer at https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/PacUmAmrWrk
LLE: If still having issues delete the out folder altogether and rerun gclient runhooks; then the ninja -C out\Debug command
How to build app with source of openssl, without compiled openssl.dll and libeay.dll ?
I downloaded openssl-0.9.8h, set include paths to path-to-sources/include/. Files located in include/openssl/ it's links to files ../../{crypto/_algo-name_/algosource.h}, and VS do not understand this links.
Actually, you need to build OpenSSL and that will generate the library and header files in the patch specified in makefile. And you should use that include files. These header files are like template files and used while building OpenSSL. See this question.
And search how to build OpenSSL on Windows.
As the problem mentioned by you after compilation, there should not be any need of OpenSSL, you can do it in the following manner:
Generate static library of OpenSSL and use it in your application. Now, after compilation of your application, OpenSSL dlls will not be required.
If your application is very small, you can compile it with OpenSSL static library.
How to build app with source of openssl, without compiled openssl.dll and libeay.dll
You cannot. You need to build the OpenSSL library first.
I downloaded openssl-0.9.8h, set include paths to path-to-sources/include/....
Your next step is to open INSTALL.W32 and read the instructions. Here's an exceprt with most of the steps. But be sure to execute it using a Visual Studio Command Prompt so the tools like cl.exe and link.exe are on path.
If you want to compile in the assembly language routines with Visual
C++, then you will need already mentioned Netwide Assembler binary,
nasmw.exe or nasm.exe, to be available on your %PATH%.
Firstly you should run Configure with platform VC-WIN32:
> perl Configure VC-WIN32 --prefix=c:\some\openssl\dir
Where the prefix argument specifies where OpenSSL will be installed to.
Next you need to build the Makefiles and optionally the assembly
language files:
- If you are using NASM then run:
> ms\do_nasm
- If you don't want to use the assembly language files at all then run:
> perl Configure VC-WIN32 no-asm --prefix=c:/some/openssl/dir
> ms\do_ms
If you get errors about things not having numbers assigned then check the
troubleshooting section: you probably won't be able to compile it as it
stands.
Then from the VC++ environment at a prompt do:
> nmake -f ms\ntdll.mak
If all is well it should compile and you will have some DLLs and
executables in out32dll. If you want to try the tests then do:
> nmake -f ms\ntdll.mak test
To install OpenSSL to the specified location do:
> nmake -f ms\ntdll.mak install
Thomas Hruska of Shining Light Productions offers Win32 OpenSSL. Its a pre-built OpenSSL with a Windows installer. He's been providing it for years.
Once installed, just point to it in Visual Studio. There's no fussing with environments like Cygwin, Perl and scripts to modify source code so that Unix and Linux work on Windows. (That's a dumb idea to me. Windows is Windows, and Linux is Linux. Stop trying to make one act like the other).
I tried to build the Boost library for native 64bit using MinGW64 compiler, but got some failures. Any pointers are appreciated. Thanks.
I got the bjam.exe (b2.exe) compiled in 64bit (with warning) and I used it the get the Boost built. I got the following error when building Boost.Context. (I wrote the command in batch for repeatable building). Anything I missed?
Command: b2.exe install --prefix=%~dp0\bld\Boost.Build
Error: 'ml64' is not recognized as an internal or external command, operable program or batch file.
I read the documentation and it said:
Boost.Context must be built for the particular compiler(s) and CPU architecture(s)s being targeted. Boost.Context includes assembly code and, therefore, requires GNU AS for supported POSIX systems, and MASM for Windows systems.
So, is it possible to tell the bjam to use the as.exe included in my MinGW installation?
(As I have multiple MinGW, the location is not standard as C:\MinGW\bin)
project-config.jam
import option ;
using gcc ;
option.set keep-going : false ;
Platform
Windows 7 x64
Boost 1.52.0 (source from sourceforge)
MinGW 4.7.2 (rubenvb x64)
No MSVC installation (no ml64.exe installed/found in my machine)
Edit Problems occurred when installing WDK
Warning when building BJam, I think it can be ignored
function.c: In function 'check_alignment':
function.c:222:5: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
Full batch
SET OPATH=%PATH%
SET BOOST_VER=boost_1_52_0
SET "PATH_ZIP=C:\Program Files\7-zip"
SET "PATH_MINGW=C:\MinGW\rubenvb-4.7.2-64"
SET "PATH_SRC=%~dp0\%BOOST_VER%"
SET "PATH_BJAM=%PATH_SRC%\tools\build\v2\engine"
TITLE Extracting Packages ...
IF NOT EXIST "%PATH_SRC%.7z" GOTO :err_nozip
RD /S /Q "%PATH_SRC%"
"%PATH_ZIP%"\7z x "%PATH_SRC%.7z"
TITLE Building BJam ...
PUSHD "%PATH_BJAM%"
SET "PATH=%PATH_MINGW%\bin"
SET "BOOST_JAM_TOOLSET_ROOT=%PATH_MINGW%\"
CALL build.bat mingw --show-locate-target
SET PATH=%OPATH%
COPY "bin.ntx86_64\b2.exe" "%PATH_SRC%\" > nul
COPY "bin.ntx86_64\bjam.exe" "%PATH_SRC%\" > nul
POPD
TITLE Installing Boost Build...
PUSHD "%PATH_SRC%"
ECHO import option ; > project-config.jam
ECHO. >> project-config.jam
ECHO using gcc ; >> project-config.jam
ECHO. >> project-config.jam
ECHO option.set keep-going : false ; >> project-config.jam
ECHO. >> project-config.jam
b2.exe install --prefix=%~dp0\bld\Boost.Build
POPD
SET PATH=%OPATH%
This is a known issue for building Boost >~1.51 with MinGW. At the moment, building Boost with MinGW is broken because Boost has a dependency on MASM (in your case ml64) when building Boost::Context for Windows, even with MinGW.
As a bodge you can get MASM from the Microsoft Website: http://www.microsoft.com/en-gb/download/details.aspx?id=12654 for a 32-bit version, or else the Windows Driver Kit for the 64-bit version: http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx
You can use the patch provided on the Boost bug tracker here: https://svn.boost.org/trac/boost/ticket/7262 though to make Boost::Context compile with just MinGW, thus re-enabling cross-compilation of Boost. You can also read the responses by Boost's Olli on the subject and his response to the subject. Don't expect anything to be fixed in Boost for a while at least!
Posting this answer here for the benefit of Google, because I've been struggling with this problem all day, and finally found a solution.
Boost context will fail to link under MinGW if built with MASM 6, because it produces the EXPORT symbol.
This manifests as undefined reference to `make_fcontext' even though the library is linked correctly.
Objdump on the resulting library gives make_i386_ms_pe_masm.o: File format not recognized.
The solution is to make sure you're using MASM 8.
You can download it at http://www.microsoft.com/en-us/download/confirmation.aspx?id=12654 - the installer will bitch about needing to have VC installed, but you can just bypass this by extracting the contents of the installer using a tool such as WinRAR; extract setup.exe and extract again to get a .cab, and extract a third time and rename the resulting binary file to ml.exe.
Then rebuild Boost with bjam --toolset=gcc --with-context -a stage.
Hopefully someone googling the same terms I've been googling all day will find this helpful.
According to Boost's requirements, you can find MASM64 in Microsoft's Windows Driver Kit (WDK).
I downloaded WDK 7 from Microsoft Download Center, and after installing it, I found ml64.exe in bin\x86\amd64. With that, I was able to successfully compile Boost 1.53.0.
(If this is relevant still) This happens when your build folders have msvc artifacts left in there. I'm assuming your project-config.jam was initially
import option ;
using msvc ;
and you had built for msvc then changed to "using gcc" In that case you need to issue the following first
bjam --clean
which should clear the artifacts from msvc build and then you can issue and things should be fine
bjam toolset=gcc variant=..... and so on and on
by the way I saw you writing you had Windows 7 x64. your bjam command needs to have adress-model=64 otherwise 32bit binaries will be produced...
A bit late maybe but I managed to compile boost-modular (the Git repository, so should be similar to 1.55 as of July 2014) on Windows 7, using MinGW and the WDK 7.
The steps I used were
install MinGW and Msys (bash etc) using mingw-get-setup (the easy way), add bin/ to path
install the Windows Driver Kit (for W7 I used WDK 7) -- GRMWDK_EN_7600_1.ISO
downloading the ISO image and extracting the files with WinRAR worked for me
the installer advises against installing the DSF, so skip that
add the directories of ML64.exe and ML.exe to the path (both required AFAIK)
C:\Windows\WinDDK\7600.16385.1\bin\x86\amd64;C:\Windows\WinDDK\7600.16385.1\bin\x86
open cmd.exe as administrator and start bash
in the parent dir of boost, run
git clone --recursive https://github.com/boostorg/boost.git boost > clone.log
exit bash, goto directory boost and run: bootstrap gcc
if that finishes w/o problems (if ML64.exe is found), run
b2 -a -d+2 -q --build-type=complete --build-dir=build toolset=gcc link=shared runtime-link=shared threading=multi
Without explicitly adding the ML(64) directories to the path, I still got the errors about ML.
Installing MASM is not the same as installing MSVC. I tried using different assemblers first but boost is not compatibe with their output.
I am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b
I'm using libcurl in a Win32 C++ application.
I have the curllib.vcproj project added to my solution and set my other projects to depend on it.
How do I build it with SSL support enabled?
Well, since this post failed badly, I had to dig into the matter myself.
Also check out the other answers and comments for additional info regarding other versions etc.
EDIT: Since I posted this Q there seems to be ready-built binaries made available from the curl homepage. Check out James' answer.
So here goes:
-
Preprocessor
The following two symbols need to be fed to the preprocessor to enable SSL for libcurl:
USE_SSLEAY
USE_OPENSSL
(libcurl uses OpenSSL for SSL support)
Alternatively the symbols can be added directly to a file called setup.h in libcurl, but I'm not too happy about modifying code in 3rd party distributions unless I really have to.
Rebuilding the libcurl library, I now got some errors about OpenSSL include files not being found. Naturally, since I haven't set up the OpenSSL distribution properly yet.
Compiling OpenSSL binaries
I downloaded the OpenSSL 0.9.8 source distribution and unpacked it.
In the root of the source distribution there's a file called INSTALL.W32 which describes how to compile the OpenSSL binaries. The build chain requires perl, so I installed the latest version of ActivePerl.
I had some trouble with the build, which might not be applicable to all systems, but I'll go through it here in case somebody experiences the same.
According to INSTALL.W32:
Run the following commandline tasks with current directory set to the source distribution root:
1> perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
(Where "c:/some/openssl/dir" should be replaced by the dir where OpenSSL should be installed. Don't use spaces in this path. The compilation further ahead will fail in that case)
2> ms\do_ms
For me this step was unsuccessful at first, since I lacked the environment variables OSVERSION and TARGETCPU. I set these to 5.1.2600 and x86 respectively. You may get complaint about OSVERSION being "insane", but look closer, this error is for WinCE and doesn't affect the Win32 setup. To get hold of your OS version, run the 'ver' command from a command prompt or run winver.exe.
3> nmake -f ms\nt.mak (for static library)
or
3> nmake -f ms\ntdll.mak (for DLL)
The source now compiles. Took approx 5 minutes on my laptop.
When compilation is completed, the libs or binaries have been placed in:
distroot/out32 - for static library build
or
distroot/out32dll - for DLL build
Building and linking
Now, back to visual studio and point out the libs and include path for headers. The include files are located in distroot/inc32/openssl.
Remember to add libeay32.lib and ssleay32.lib as linker input.
Rebuild the libcurl project.
Error!
Well at least for me with this version of OpenSSL.
it complained about a struct typedef in one of the OpenSSL headers. I couldn't find any info on this. After an hour of googling I broke my own principle and commented out the typedef from the OpenSSL header, and luckily libcurl wasn't using that symbol so it built fine.
Update: As pointed out by Jason, this issue seems to have dissapeared as of version 1.0.0a.
Now, for confirming that SSL support is enabled for libcurl, run the following code:
curl_version_info_data * vinfo = curl_version_info( CURLVERSION_NOW );
if( vinfo->features & CURL_VERSION_SSL )
// SSL support enabled
else
// No SSL
Simple as that.
Maybe this isn't the answer anyone is looking for, but I simply just downloaded the precompiled DLLs from this link found at http://curl.haxx.se/download.html
I ran the test that sharkin provided, and if( vinfo->features & CURL_VERSION_SSL ) proved to be true.
Following Robert Oschler's advice, here is my comment on the question as answer :
You can build recent libcurl (2012) with native SSL support for windows using the preprocessor symbols: USE_WINDOWS_SSPI and USE_SCHANNEL instead of the OpenSSL ones.
When compiling OpenSSL 1.0.0 on Windows with Visual Studio 2010, it eventually threw a 0x2 error:
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\BIN\cl.EXE"' : return code '0x2'
Stop.
It seems that this error will be thrown because of a flag in the perl Configure file, namely -WX.
As the MSDN documentation states:
Treats all compiler warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
After removing the -WX occurrences in the Configure file and re-entering the commands stated here it built fine and passed all tests.
In my case follow the curl README file was enough.
My configuration is the following:
Visual Studio 2015 (VC14)
Static library
Win64
curl version 7.57.0
OpenSSL 1.0.2
Compilation of libCurl
Download libcurl source there: https://curl.haxx.se/download.html
Uncompress the file and go to the folder curl-7.57.0\projects
Open the README file and follow the instructions, this lead me to do the following:
Downloaded OpenSSL
Extract it and rename it to openssl, put it aside the curl folder, this is important as you'll open the VS project that expect to find openssl there.
Install Perl
Execute the utility build-openssl.bat to perform the compilation of openSSL. With my settings this became the following:
.\build-openssl.bat vc14 x64 release ..\..\openssl\
just runs .\build-openssl.bat -help to know more about the parameters.
After that you can see OpenSSL has been compiled as you got a new folder here: openssl\build\Win64
Open the Visual Studio project curl-7.57.0\projects\Windows\VC14\curl-all.sln
Be sure to set the visual studio project to the build configuration you need (LIB Release - LIB OpenSSL in my case)
Build all
The library is located at curl-7.57.0\build\Win64\VC14\LIB Release - LIB OpenSSL\libcurl.lib
Remarks
Don't forget to define the CURL_STATICLIB preprocessor in your own project
With static library, you will have to links with the dependencies of libcurl, see this answer
You might not want to depend on LDAP, in that case you can disable it by setting the preprocessor CURL_DISABLE_LDAP before you compile libcurl.
If you build with Visual Studio IDE and get 58 odd warnings as the likes of
"inconsistent dll linkage curl_global_init / curl_msnprintf /..."
you should add CURL_STATICLIB to the preproccessor definitions.
so the entire definition line should look like:
USE_SSLEAY;USE_OPENSSL;CURL_STATICLIB.
With this all the warning will disappear.
Some would ignore the warnings and go on using the libs, but then will get corresponding *error*s as the likes of curl_global_init / curl_msnprintf. It can be very annoying.
Hope it can help somebody.
\ fatal error C1083: Cannot open include
file: 'stdlib.h': No such file or directory
NMAKE: fatal error U1077::return code
That error can be solved by executing vcvarsall.bat in Visual Studio.
How to build libcurl C/C++ with OpenSSL (SSL support) on Windows
Install libcurl
Install OpenSSl
Build libcurl with OpenSSL
Installing libcurl
Go to the download page of libcurl and donwnload the ZIP file under Source Archives. In my case it is called curl-7.58.0.zip
Extract the archive and open projects/Windows/VC15/curl_all.sln with Visual Studio.
Installing OpenSSL
Download the windows binary of OpenSSL. In my case, I downloaded the windows installer file Win32 OpenSSL v1.1.0g from the Shining Light Productions distribution.
The installation folder for me is C:\OpenSSL-Win32.
Building libcurl with OpenSSL
In the curl_all.sln Visual Studio solution file, change the build configuration to DLL Debug - DLL OpenSSL.
In the Solution Explorer, right click the project curl and go to Properties.
Under Linker -> General modify Additional Library Directories and add the path to your OpenSSL directory + \lib. In my case, this is C:\OpenSSL-Win32\lib.
Apply and close the properties window.
Right click the project libcurl and do the same as the previous step, add OpenSSL directory + \lib to Additional Library Directories under Linker -> General.
Under C/C++ -> General, add C:\OpenSSL-Win32\include to the Additional Include Directories.
Finally go to Linker -> Input and modify Additional Dependencies. Replace all the lib files to the following:
ws2_32.lib
wldap32.lib
openssl.lib
libssl.lib
libcrypto.lib
Apply and close the properties window.
With the DLL Debug - DLL OpenSSL build configuration still selected, go to Build -> Build Solution.
Copy the two dll files libcrypto-1_1.dll and libssl-1_1.dll from the OpenSSL bin directory (C:\OpenSSL-Win32\bin) to the just created build directory curl-7.58.0\build\Win32\VC15\DLL Debug - DLL OpenSSL.
Validating Build
Inside the build directory, run curld.exe. If it runs with no errors (missing dll, etc.) then your build was successful.
i did "do_nt.bat" for windows 7 rc7100
don't forget "nmake -f ms\nt.mak install" to copy the headers correctly
thanks this did help a lot
Couple of notes in response to and/or in addition to the above..
First, if you don't want to mess with ActivePerl, Strawberry Perl is terrific and worked perfectly for this.
Second, in lieu of using do_ms.bat, I would recommend preferring do_masm if possible since, according to INSTALL.W32,
This is worth doing because it will
result in faster code: for example it
will typically result in a 2 times
speedup in the RSA routines.
Also, build 0.9.8l (L) of OpenSSL was a nightmare so I eventually gave up and reverted to 0.9.8k which built and linked (statically) with libcurl 1.9 without issue.