Build on Windows for Windows: Does not run due to missing vcruntime140.dll

[ideafarm]

This is a request to reopen issue *8040. IMO, the build should do one of:

(1) Produce binaries that statically link to vcruntime140.dll, or (2) Copy that dll into the bin directory, or (3) Document that OpenSSL can only be used on systems for which X has been installed.

The size of the most recent version that I have is only 101,872 bytes.

(I vote for alternative 1, since the size is so small. If it was larger, I would vote for 2.)

Postscript: Copying this dll to the executable directory is not sufficient. This really does need to be fixed. OpenSSL is unusable on Windows systems that do not have other software, such as Visual Studio, installed.

[makr]

Well, I am voting for (3) 😄 ... ... or for (4): make it a configurable option.

Reason: when shipping compiled openssl binaries our installer ensures the MSVC runtime is or gets installed. We need it anyway.

[levitte]

(5) Avoid vcruntime140.dll... this is what we've done before, and we had developers in the team before that were very attentive to this problem... we've slipped.

I just did a dumpbin /imports apps\openssl.exe:

    VCRUNTIME140.dll
             140049150 Import Address Table
             140070AA8 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                           8 __C_specific_handler
                          3B memcmp
                          3E memset
                          42 strstr
                          3C memcpy
                          41 strrchr
                          40 strchr

Weirdest thing is that there are other string functions that are implemented in completely different DLLs... I have no idea why these had to be specifically in vcruntime140.dll.

[ideafarm]

Now I vote for (5), too. My dumpbin list is slightly different, but no less trivial. These tiny routines do not justify allowing a dependency to exist. Dependencies are snowballs that become avalanches of problems. Can't the VS compiler be told to link these C routines in statically? I'm unfamiliar with this compiler but am willing to help get this done.

VCRUNTIME140.dll
            45009C Import Address Table
            4791B0 Import Name Table
                 0 time date stamp
                 0 Index of first forwarder reference

               4A strchr
               46 memcpy
               48 memset
               4B strrchr
               47 memmove
               4C strstr
               1C __current_exception
               1D __current_exception_context
               35 _except_handler4_common

[levitte]

Ah, thanks for reminding me... I went looking, and ta-daaaa, there's a libvcruntime.lib

Ref: https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=vs-2019

The flip side is that is VC 2015 and on, so we need to be careful when and when not to include this in the list of libraries to link with.

I'll try to get back to this in the coming week

[levitte]

@ideafarm, would you mind giving me some data on the OpenSSL version and how you built it? The latter should be possible to show with the output of this command if it's OpenSSL 1.1.1: perl configdata.pm -c

[ideafarm]

d:\git\openssl\apps>openssl version OpenSSL 3.0.0-alpha4-dev (Library: OpenSSL 3.0.0-alpha4-dev ) (Cloned from https://github.com/ideafarm/openssl using GitHub Desktop.)

d:\git\openssl>perl -v This is perl 5, version 30, subversion 2 (v5.30.2) built for MSWin32-x64-multi-thread Copyright 1987-2020, Larry Wall

d:\git\openssl>perl configdata.pm -c

Command line (with current working directory = .):

C:\Strawberry\perl\bin\perl.exe Configure VC-WIN32

Perl information:

C:\Strawberry\perl\bin\perl.exe
5.30.2 for MSWin32-x64-multi-thread

[ideafarm]

I can't use OpenSSL if my potential users must install OpenSSL or Visual Studio. This is not a feature; it is a BUG! I just verified that the current build of openssl.exe still imports dynamically from VCRUNTIME140.dll:

               4A strchr
               46 memcpy
               48 memset
               47 memmove
               4C strstr
               4B strrchr
               1C __current_exception
               1D __current_exception_context
               35 _except_handler4_common

This is going to force me to migrate away from using OpenSSL. :(

P.S. I've found two files that tell nmake to use the "wrong" Visual Studio runtime. I've edited those files and am currently building to see if the changes fix this BUG.

[ideafarm]

I just realized that I am being stupid. My users can install the runtime, or my installer can do it for them.

[ideafarm]

I would REALLY like this to be fixed. It's just stupid for OpenSSL to require the installation of Visual Studio runtimes just so it can call some tiny general string manipulation functions that could be linked in statically from the standard C library. I'm willing to do all of the grunt work to fix this if someone who is familiar with the OpenSSL code would mentor and guide me.

[nhorman]

Marking as inactive, to be closed at the end of 3.4 dev, barring further input

[sutyak]

I ran into this with the 3.0.9 FIPS version. My solution was to install the C++ redistributable, locate the cab file by searching the registry, extract and rename those DLLs, then include them in the bin folder of openssl. There are only 11 files with a combined size of 1.9MB. An easy enough solution until there's a 3.4+ FIPS version available.