Error building OpenSSL-1.1.1g

[Michael Wojcik]

[Removed the top-posted mess of history from this reply.]

In response to various questions posed in this thread:

> Can someone point me to sources of information about how to resolve this issue?

Probably not, because it's not clear how you got into this state in the first place. You have a mix of 32- and 64-bit tools in your toolchain for this build. I don't know what you did to get there; I've never seen that happen with any of my OpenSSL builds.

> I simply don't believe I'm the only one who wants to build OpenSSL for use in a
> Windows 10 environment - someone must have been successful and be able to point
> me to additional information.

That's good, because that would be a silly thing to believe. We have multiple teams that routinely build OpenSSL for Windows (and other platforms). I've built it myself any number of times. We build both 32- and 64-bit variants, without problems.

My suggestion: Follow the recommended process by installing nasm (it's free) and configuring for that instead of MASM. As Matt suggested, start from a "Visual Studio Command Prompt" window for the bitness you want to build, and then make sure you configure for that bitness. Get rid of any existing build artifacts first - probably the easist way is to move your working directory aside and extract a fresh one from the tarball.

As Matt noted, you can confirm whether you're using the 32- or 64-bit version of the Visual Studio toolchain just by running cl.exe with no parameters; the banner says "for x86" or "for x64". Note that it's important to let Visual Studio set up the environment (using one of those "Visual Studio Command Prompt" options) rather than trying to set it up manually - the latter is possible (I do it for my Cygwin bash sessions), but it's a pain to get it right.

> I messed around quite a bit trying to figure out how I might modify the build
> process to work with my usual set of tools - mostly UNIX-tools ported to Windows
> environment.  My preference would be to find pointers to information of how to
> accomplish that.

Unless your usual set of tools matches what OpenSSL wants for the MinGW+MSYS2 configuration option, I'd strongly recommend not trying to do this unless and until you understand the OpenSSL build process very well.

Regarding MSYS2 and Perl:

- Did you read the updated NOTES.WIN that Matt posted a link to?

- Perl implementations for Windows vary widely in their idiosyncracies, and OpenSSL is finicky about them. For years we used Cygwin Perl, but had to run it under a wrapper program which altered the command-line arguments. These days, we use Strawberry Perl. ActiveState Perl has also worked, but has licensing issues when used to build commercial software; that probably doesn't apply in your case. Note Strawberry and ActiveState have Windows-native behavior, and thus can be expected to work for the Visual Studio configurations but probably not for the MSYS2 configurations.
   In my experience, getting Perl to cooperate is the biggest hurdle in building OpenSSL on Windows, and historically for us has been the most fragile aspect. As the OpenSSL build process has made heavier use of Perl, it's become more picky about getting a Perl it likes. (This is probably my least favorite aspect of OpenSSL. People complain about the OpenSSL source, but I'd much rather debug that than the Perl build scripts.)

- You haven't told us what Perl implementation you're using. Knowing the path to it doesn't help us. (Though, to be honest, knowing which implementation it is probably isn't terribly useful either.) It would be nice if Sergio told us which one *he's* using, since it's known to work with the MSYS2 configurations.

- I don't know whether there are Perl implementations for Windows specifically intended to be used with MinGW or MSYS2, and if so whether they work for the OpenSSL build. Oh, wait: I just did a quick search, and apparently there is an MSYS2 Perl package available from repo.msys2.org. Does it work with the OpenSSL build? I don't know, but it seems like it's worth a try.

--
Michael Wojcik
Distinguished Engineer, Micro Focus