Error building OpenSSL-1.1.1g

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Error building OpenSSL-1.1.1g

mhkelley2017

Error:  'ml64' is not recognized as an internal or external command,

operable program or batch file.

 

Platform: Windows 10

Intended context for use: Mingw-64, Qt 5.15

Building with Visual Studio  2019 Community

Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

 

Configuration commands:

perl Configure VC-WIN64A-masm --prefix=%PREFIX%

 

Error output:

 

cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes "crypto\aes\aes_wrap.c" 2>&1 > crypto\aes\aes_wrap.d

        set ASM=ml64

        "C:\Perl64\bin\perl.exe" "crypto\aes\asm\aesni-mb-x86_64.pl" masm crypto\aes\aesni-mb-x86_64.asm

        ml64  /c /Cp /Cx /nologo /Zi /Focrypto\aes\aesni-mb-x86_64.obj "crypto\aes\aesni-mb-x86_64.asm"

'ml64' is not recognized as an internal or external command,

operable program or batch file.

NMAKE : fatal error U1077: 'ml64' : return code '0x1'

Stop.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"' : return code '0x2'

Stop.

 

Initial build output:

 

Configuring OpenSSL version 1.1.1g (0x1010107fL) for VC-WIN64A-masm

Using os-specific seed configuration

Creating configdata.pm

Creating makefile

 

**********************************************************************

***                                                                ***

***   OpenSSL has been successfully configured                     ***

***                                                                ***

***   If you encounter a problem while building, please open an    ***

***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***

***   and include the output from the following command:           ***

***                                                                ***

***       perl configdata.pm --dump                                ***

***                                                                ***

***   (If you are new to OpenSSL, you might want to consult the    ***

***   'Troubleshooting' section in the INSTALL file first)         ***

***                                                                ***

**********************************************************************

 

c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g>nmake

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\crypto\bn_conf.h.in" > include\crypto\bn_conf.h

        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\crypto\dso_conf.h.in" > include\crypto\dso_conf.h

        "C:\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl"  "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h

        "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" /                   depend && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe" /                   _all

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

 

Microsoft (R) Program Maintenance Utility Version 14.26.28806.0

Copyright (C) Microsoft Corporation.  All rights reserved.

 

        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "." /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Foapps\app_rand.obj "apps\app_rand.c"

app_rand.c

 

*** lots of similar output before fatal error

Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: Thursday, June 25, 2020 11:54

> Error:  'ml64' is not recognized as an internal or external command,
> operable program or batch file.

It's part of Visual C. The VC-WIN64A-masm configuration (Configurations/50-masm.conf) specifies it as the assembler.

> Building with Visual Studio  2019 Community

Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or maybe it's part of some optional component?

In VS2017 Professional, which is what I have configured at the moment on this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks to VS's gratuitously complicated directory layout.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: Error building OpenSSL-1.1.1g

Matt Caswell-2


On 25/06/2020 18:32, Michael Wojcik wrote:
>> From: openssl-users [mailto:[hidden email]] On Behalf Of [hidden email]
>> Sent: Thursday, June 25, 2020 11:54
>
>> Error:  'ml64' is not recognized as an internal or external command,
>> operable program or batch file.
>
> It's part of Visual C. The VC-WIN64A-masm configuration (Configurations/50-masm.conf) specifies it as the assembler.

Note that using masm to compile OpenSSL is no longer supported by us
(although it might still work).

Preferred is to use the VC-WIN64A target and the nasm compiler.

If you use the Developer Studio command prompt (64-bit) it should have
all the environment variables set up already to find the various VS tools.

Matt


>
>> Building with Visual Studio  2019 Community
>
> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or maybe it's part of some optional component?
>
> In VS2017 Professional, which is what I have configured at the moment on this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks to VS's gratuitously complicated directory layout.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
Thanks! That helped, but I have two follow-ups.

1) To whom would I suggest minor changes to the available installation
instructions to help avoid future such misunderstandings?
2) A subsequent fatal error (should this also be submitted as a new
thread?):

        Could Not Find
c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.

*** build output ***
cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I "."
/I "include" -D"L_ENDIAN" -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ"
-D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AESNI_ASM" -D"VPAES_ASM"
-D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\usr\\local\\OPENSSL\\openssl-1.1.1g\\x86_64-8.1.0-posix-
seh-rt_v6-rev0\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes "ms\uplink.c" 2>&1 >
ms\uplink.d
        "C:\Perl64\bin\perl.exe" "util\mkdef.pl" crypto 32 > libcrypto.def
        IF EXIST .manifest DEL /F /Q .manifest
        IF EXIST libcrypto-1_1-x64.dll DEL /F /Q libcrypto-1_1-x64.dll
        link /nologo /debug /dll  /nologo /debug  /implib:libcrypto.lib
/out:libcrypto-1_1-x64.dll /def:libcrypto.def
@C:\Users\Owner\AppData\Local\Temp\nm26DC.tmp || (DEL /Q libcrypto-1_1-x64.*
libcrypto.lib && EXIT 1)
crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
'x64' conflicts with target machine type 'x86'
Could Not Find
c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
: return code '0x2'
Stop.

-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt
Caswell
Sent: Thursday, June 25, 2020 12:15 PM
To: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g



On 25/06/2020 18:32, Michael Wojcik wrote:
>> From: openssl-users [mailto:[hidden email]] On Behalf
Of [hidden email]
>> Sent: Thursday, June 25, 2020 11:54
>
>> Error:  'ml64' is not recognized as an internal or external command,
>> operable program or batch file.
>
> It's part of Visual C. The VC-WIN64A-masm configuration
(Configurations/50-masm.conf) specifies it as the assembler.

Note that using masm to compile OpenSSL is no longer supported by us
(although it might still work).

Preferred is to use the VC-WIN64A target and the nasm compiler.

If you use the Developer Studio command prompt (64-bit) it should have
all the environment variables set up already to find the various VS tools.

Matt


>
>> Building with Visual Studio  2019 Community
>
> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
maybe it's part of some optional component?
>
> In VS2017 Professional, which is what I have configured at the moment on
this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
to VS's gratuitously complicated directory layout.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Error building OpenSSL-1.1.1g

Matt Caswell-2


On 25/06/2020 20:20, [hidden email] wrote:
> Thanks! That helped, but I have two follow-ups.
>
> 1) To whom would I suggest minor changes to the available installation
> instructions to help avoid future such misunderstandings?

You can raise on issue on Github. Or even better raise a PR with your
suggested changes. However, as it so happens the Windows instructions
have very recently been significantly updated - so some of your
suggestions may already have been included:

https://github.com/openssl/openssl/pull/12098

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

This usually occurs when attempting to build 64-bit OpenSSL using the
32-bit VisualStudio tools.

Matt



> Could Not Find
> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
> NMAKE : fatal error U1077: 'link' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
> : return code '0x2'
> Stop.
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt
> Caswell
> Sent: Thursday, June 25, 2020 12:15 PM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 25/06/2020 18:32, Michael Wojcik wrote:
>>> From: openssl-users [mailto:[hidden email]] On Behalf
> Of [hidden email]
>>> Sent: Thursday, June 25, 2020 11:54
>>
>>> Error:  'ml64' is not recognized as an internal or external command,
>>> operable program or batch file.
>>
>> It's part of Visual C. The VC-WIN64A-masm configuration
> (Configurations/50-masm.conf) specifies it as the assembler.
>
> Note that using masm to compile OpenSSL is no longer supported by us
> (although it might still work).
>
> Preferred is to use the VC-WIN64A target and the nasm compiler.
>
> If you use the Developer Studio command prompt (64-bit) it should have
> all the environment variables set up already to find the various VS tools.
>
> Matt
>
>
>>
>>> Building with Visual Studio  2019 Community
>>
>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
> maybe it's part of some optional component?
>>
>> In VS2017 Professional, which is what I have configured at the moment on
> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
> to VS's gratuitously complicated directory layout.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

Michael Wojcik
In reply to this post by mhkelley2017
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> [hidden email]
> Sent: Thursday, June 25, 2020 14:20

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

For some reason - I can't tell based on what you sent - your build has told the linker to output a 32-bit DLL instead of a 64-bit one. This object is 64-bit, and you appear to be trying to build the 64-bit DLL, but the linker thinks it's linking for 32-bit.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
In reply to this post by Matt Caswell-2
Thank you.  I suspected as much.

Can someone point me to sources of information about how to resolve this issue?  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.

A few points that may be useful and then two specific questions.

1. I program exclusively for a Windows environment.  Most of what I develop should be portable, but it as almost exclusively for my own use, which is presently almost exclusively Windows.  I *may* at some future point go back to Linux, but not yet.

2. I have never used (or seen need to use) Visual Studio.  I downloaded a copy specifically to get this package installed.  I attempted to install for 64-bit use.   But it is not entirely clear to me to know which pars are actually being used.  Usually, I would have just used Mingw-w64 along with Windows ports of the standard complement of UNIX tools.  While I do have access to Cygwin, my preference is to either stick with Windows or make t full change back to UNIX.

3. I have built and installed a significant number of software packages, so am not really a newbie, but there are clear gaps in my knowledge and experience.

4. Before installing Visual Studio, 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.

THE SPECIFIC QUESTIONS:

1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?

2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?

I'd really appreciate any useful information or pointers to such.

Thanks.


-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
Sent: Thursday, June 25, 2020 2:03 PM
To: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g



On 25/06/2020 20:20, [hidden email] wrote:
> Thanks! That helped, but I have two follow-ups.
>
> 1) To whom would I suggest minor changes to the available installation
> instructions to help avoid future such misunderstandings?

You can raise on issue on Github. Or even better raise a PR with your
suggested changes. However, as it so happens the Windows instructions
have very recently been significantly updated - so some of your
suggestions may already have been included:

https://github.com/openssl/openssl/pull/12098

> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
> 'x64' conflicts with target machine type 'x86'

This usually occurs when attempting to build 64-bit OpenSSL using the
32-bit VisualStudio tools.

Matt



> Could Not Find
> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
> NMAKE : fatal error U1077: 'link' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
> : return code '0x2'
> Stop.
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt
> Caswell
> Sent: Thursday, June 25, 2020 12:15 PM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 25/06/2020 18:32, Michael Wojcik wrote:
>>> From: openssl-users [mailto:[hidden email]] On Behalf
> Of [hidden email]
>>> Sent: Thursday, June 25, 2020 11:54
>>
>>> Error:  'ml64' is not recognized as an internal or external command,
>>> operable program or batch file.
>>
>> It's part of Visual C. The VC-WIN64A-masm configuration
> (Configurations/50-masm.conf) specifies it as the assembler.
>
> Note that using masm to compile OpenSSL is no longer supported by us
> (although it might still work).
>
> Preferred is to use the VC-WIN64A target and the nasm compiler.
>
> If you use the Developer Studio command prompt (64-bit) it should have
> all the environment variables set up already to find the various VS tools.
>
> Matt
>
>
>>
>>> Building with Visual Studio  2019 Community
>>
>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
> maybe it's part of some optional component?
>>
>> In VS2017 Professional, which is what I have configured at the moment on
> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
> to VS's gratuitously complicated directory layout.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Error building OpenSSL-1.1.1g

Matt Caswell-2


On 26/06/2020 00:47, [hidden email] wrote:
> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?

My windows environment died on my recently, so I can't check the actual
output. IIRC just typing "cl" at the command line should give you
details about the compiler being used and whether it is for 32 or 64 bits.

Visual Studio has a number of "developer command prompts" available with
it. If you start one of those it should have all the right environment
variables set up for you. There should be different command prompts for
32 bit vs 64 bit.

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

Alternatively there is the vcvarsall.bat script which comes with VS that
enables you to setup all the environment variables - you can specify as
an argument to script whether you are targeting 32 bit or 64 bit.

https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

As well as the VS tools environment variables you will need to make sure
both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
%PATH%.


>
> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?

You can do this using the MinGW compilers and the MSys2 shell. Note the
MinGW compilers target *native* windows. So although you use Msys2 to
build it, the resulting binaries are fully native.


There are details in the newly rewritten instructions for Windows:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN

Matt


>
> I'd really appreciate any useful information or pointers to such.
>
> Thanks.
>
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
> Sent: Thursday, June 25, 2020 2:03 PM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 25/06/2020 20:20, [hidden email] wrote:
>> Thanks! That helped, but I have two follow-ups.
>>
>> 1) To whom would I suggest minor changes to the available installation
>> instructions to help avoid future such misunderstandings?
>
> You can raise on issue on Github. Or even better raise a PR with your
> suggested changes. However, as it so happens the Windows instructions
> have very recently been significantly updated - so some of your
> suggestions may already have been included:
>
> https://github.com/openssl/openssl/pull/12098
>
>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>> 'x64' conflicts with target machine type 'x86'
>
> This usually occurs when attempting to build 64-bit OpenSSL using the
> 32-bit VisualStudio tools.
>
> Matt
>
>
>
>> Could Not Find
>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>> : return code '0x2'
>> Stop.
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt
>> Caswell
>> Sent: Thursday, June 25, 2020 12:15 PM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of [hidden email]
>>>> Sent: Thursday, June 25, 2020 11:54
>>>
>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>> operable program or batch file.
>>>
>>> It's part of Visual C. The VC-WIN64A-masm configuration
>> (Configurations/50-masm.conf) specifies it as the assembler.
>>
>> Note that using masm to compile OpenSSL is no longer supported by us
>> (although it might still work).
>>
>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>
>> If you use the Developer Studio command prompt (64-bit) it should have
>> all the environment variables set up already to find the various VS tools.
>>
>> Matt
>>
>>
>>>
>>>> Building with Visual Studio  2019 Community
>>>
>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>> maybe it's part of some optional component?
>>>
>>> In VS2017 Professional, which is what I have configured at the moment on
>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>> to VS's gratuitously complicated directory layout.
>>>
>>> --
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
Matt,

Thanks for your suggestion ...

>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>> 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.

That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..

Here is how far I got  I have been unable to even figure out where this error comes from ...

----------------------------------------------------------------------------------
$ where perl
C:\Perl64\bin\perl.exe
$ perl Configure mingw --prefix=$PREFIX
******************************************************************************
This perl implementation doesn't produce Unix like paths (with forward slash
directory separators).  Please use an implementation that matches your
building platform.

This Perl version: 5.24.3 for MSWin32-x64-multi-thread
******************************************************************************
Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
Using os-specific seed configuration
----------------------------------------------------------------------------------


-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 3:04 AM
To: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 00:47, [hidden email] wrote:
> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?

My windows environment died on my recently, so I can't check the actual
output. IIRC just typing "cl" at the command line should give you
details about the compiler being used and whether it is for 32 or 64 bits.

Visual Studio has a number of "developer command prompts" available with
it. If you start one of those it should have all the right environment
variables set up for you. There should be different command prompts for
32 bit vs 64 bit.

https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs

Alternatively there is the vcvarsall.bat script which comes with VS that
enables you to setup all the environment variables - you can specify as
an argument to script whether you are targeting 32 bit or 64 bit.

https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017

As well as the VS tools environment variables you will need to make sure
both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
%PATH%.


>
> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?

You can do this using the MinGW compilers and the MSys2 shell. Note the
MinGW compilers target *native* windows. So although you use Msys2 to
build it, the resulting binaries are fully native.


There are details in the newly rewritten instructions for Windows:

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN

Matt


>
> I'd really appreciate any useful information or pointers to such.
>
> Thanks.
>
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
> Sent: Thursday, June 25, 2020 2:03 PM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 25/06/2020 20:20, [hidden email] wrote:
>> Thanks! That helped, but I have two follow-ups.
>>
>> 1) To whom would I suggest minor changes to the available installation
>> instructions to help avoid future such misunderstandings?
>
> You can raise on issue on Github. Or even better raise a PR with your
> suggested changes. However, as it so happens the Windows instructions
> have very recently been significantly updated - so some of your
> suggestions may already have been included:
>
> https://github.com/openssl/openssl/pull/12098
>
>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>> 'x64' conflicts with target machine type 'x86'
>
> This usually occurs when attempting to build 64-bit OpenSSL using the
> 32-bit VisualStudio tools.
>
> Matt
>
>
>
>> Could Not Find
>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>> : return code '0x2'
>> Stop.
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt
>> Caswell
>> Sent: Thursday, June 25, 2020 12:15 PM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of [hidden email]
>>>> Sent: Thursday, June 25, 2020 11:54
>>>
>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>> operable program or batch file.
>>>
>>> It's part of Visual C. The VC-WIN64A-masm configuration
>> (Configurations/50-masm.conf) specifies it as the assembler.
>>
>> Note that using masm to compile OpenSSL is no longer supported by us
>> (although it might still work).
>>
>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>
>> If you use the Developer Studio command prompt (64-bit) it should have
>> all the environment variables set up already to find the various VS tools.
>>
>> Matt
>>
>>
>>>
>>>> Building with Visual Studio  2019 Community
>>>
>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>> maybe it's part of some optional component?
>>>
>>> In VS2017 Professional, which is what I have configured at the moment on
>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>> to VS's gratuitously complicated directory layout.
>>>
>>> --
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Error building OpenSSL-1.1.1g

Matt Caswell-2


On 26/06/2020 14:27, [hidden email] wrote:

> Matt,
>
> Thanks for your suggestion ...
>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
>
> Here is how far I got  I have been unable to even figure out where this error comes from ...
>
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
>
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
>
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 26/06/2020 00:47, [hidden email] wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
>
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
>
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
>
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
>
>
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
>
>
> There are details in the newly rewritten instructions for Windows:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>
> Matt
>
>
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks.
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, [hidden email] wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>> Of [hidden email]
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
Matt,

I fear I my wear out my welcome before I manage to get a working OpenSSL ...

> Make sure msys2 has the perl package installed and remove
> this one from your path.

OK, I'll bite.

As near as I can tell, this suggestion means one of two things.

1) use one of the "completion"  functions named "perl" that apparently came with the original MSYS2 installation (both in folder msys64\usr\share\bash-completion\completions).  Since neither seemed to do anything useful here, I presume you mean

2) install a perl package from MSYS2 for use with MSYS2.  If this is what you meant, I still have two apparently relevant choices.

a) mingw-w64-perl
b) perl (seems specific to Cygwin and Linux)

The former gives me the same error as ActivePerl
The latter seems to be just ignored.

I'm clearly missing something, but must be too dense to figure out what.

Mike

-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 7:31 AM
To: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:27, [hidden email] wrote:

> Matt,
>
> Thanks for your suggestion ...
>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
>
> Here is how far I got  I have been unable to even figure out where this error comes from ...
>
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
>
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
>
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 26/06/2020 00:47, [hidden email] wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
>
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
>
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
>
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
>
>
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
>
>
> There are details in the newly rewritten instructions for Windows:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>
> Matt
>
>
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks.
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, [hidden email] wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>> Of [hidden email]
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Error building OpenSSL-1.1.1g

Sergio NNX
In reply to this post by Matt Caswell-2
It is so easy to build OpenSSL using MinGW/MSYS!

Just type: ./Configure mingw64 ....... <whatever options you need/want>
                  make all


How much experience do you have building apps from source on Windows? VS didn't work, MinGW didn't work either!
We are more than happy to assist you.

Have fun.


From: openssl-users <[hidden email]> on behalf of Matt Caswell <[hidden email]>
Sent: Friday, 26 June 2020 11:30 PM
To: [hidden email] <[hidden email]>
Subject: Re: Error building OpenSSL-1.1.1g
 


On 26/06/2020 14:27, [hidden email] wrote:
> Matt,
>
> Thanks for your suggestion ...
>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
>
> Here is how far I got  I have been unable to even figure out where this error comes from ...
>
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
>
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
>
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 26/06/2020 00:47, [hidden email] wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
>
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
>
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
>
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
>
>
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
>
>
> There are details in the newly rewritten instructions for Windows:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>
> Matt
>
>
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks.
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, [hidden email] wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [[hidden email]] On Behalf
>>> Of [hidden email]
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017

Thanks.

 

But apparently you missed one of my earlier posts.

 

I have a fair bit of experience building apps from source.  My general experience is that the instructions provided are nearly correct, but that the user must do a little tweaking of the process – presumably because the underlying process is quite complex and depends a *very many* case-specific system configuration details.  Hence, I am quite comfortable debugging most installation processes to get them to work.

 

Following your suggestion, I get (and reported) the following result:

 

----------------------------------------------------------------------------------------

Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw64

Using os-specific seed configuration

 

******************************************************************************

This perl implementation doesn't produce Unix like paths (with forward slash

directory separators).  Please use an implementation that matches your

building platform.

 

This Perl version: 5.28.0 for MSWin32-x64-multi-thread

******************************************************************************

----------------------------------------------------------------------------------------

 

So clearly, either 1) you have done something different from just enter the configure command, or 2) I have something in my programming environment that is different from yours.

 

I’m simply trying to figure out one of those differences.

 

Mike

 

From: Sergio NNX <[hidden email]>
Sent: Friday, June 26, 2020 8:59 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g

 

It is so easy to build OpenSSL using MinGW/MSYS!

 

Just type: ./Configure mingw64 ....... <whatever options you need/want>

                  make all

 

 

How much experience do you have building apps from source on Windows? VS didn't work, MinGW didn't work either!

We are more than happy to assist you.

 

Have fun.

 


From: openssl-users <[hidden email]> on behalf of Matt Caswell <[hidden email]>
Sent: Friday, 26 June 2020 11:30 PM
To: [hidden email] <[hidden email]>
Subject: Re: Error building OpenSSL-1.1.1g

 



On 26/06/2020 14:27, [hidden email] wrote:


> Matt,
>
> Thanks for your suggestion ...
>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows
>>> 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>
> That was one of the first things I tried.  After exploring a few rabbit holes, I gave up and downloaded Visual Studio..
>
> Here is how far I got  I have been unable to even figure out where this error comes from ...
>
> ----------------------------------------------------------------------------------
> $ where perl
> C:\Perl64\bin\perl.exe
> $ perl Configure mingw --prefix=$PREFIX
> ******************************************************************************
> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.
>
> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
> ******************************************************************************

For msys2 based builds you must use the msys2 provided perl version, not
a native perl. Make sure msys2 has the perl package installed and remove
this one from your path.

Maybe we should add an FAQ section of common faults and how to fix them.

Matt




> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
> Using os-specific seed configuration
> ----------------------------------------------------------------------------------
>
>
> -----Original Message-----
> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
> Sent: Friday, June 26, 2020 3:04 AM
> To: [hidden email]
> Subject: Re: Error building OpenSSL-1.1.1g
>
>
>
> On 26/06/2020 00:47, [hidden email] wrote:
>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>
> My windows environment died on my recently, so I can't check the actual
> output. IIRC just typing "cl" at the command line should give you
> details about the compiler being used and whether it is for 32 or 64 bits.
>
> Visual Studio has a number of "developer command prompts" available with
> it. If you start one of those it should have all the right environment
> variables set up for you. There should be different command prompts for
> 32 bit vs 64 bit.
>
> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>
> Alternatively there is the vcvarsall.bat script which comes with VS that
> enables you to setup all the environment variables - you can specify as
> an argument to script whether you are targeting 32 bit or 64 bit.
>
> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>
> As well as the VS tools environment variables you will need to make sure
> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
> %PATH%.
>
>
>>
>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>
> You can do this using the MinGW compilers and the MSys2 shell. Note the
> MinGW compilers target *native* windows. So although you use Msys2 to
> build it, the resulting binaries are fully native.
>
>
> There are details in the newly rewritten instructions for Windows:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>
> Matt
>
>
>>
>> I'd really appreciate any useful information or pointers to such.
>>
>> Thanks.
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Thursday, June 25, 2020 2:03 PM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 25/06/2020 20:20, [hidden email] wrote:
>>> Thanks! That helped, but I have two follow-ups.
>>>
>>> 1) To whom would I suggest minor changes to the available installation
>>> instructions to help avoid future such misunderstandings?
>>
>> You can raise on issue on Github. Or even better raise a PR with your
>> suggested changes. However, as it so happens the Windows instructions
>> have very recently been significantly updated - so some of your
>> suggestions may already have been included:
>>
>> https://github.com/openssl/openssl/pull/12098
>>
>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>> 'x64' conflicts with target machine type 'x86'
>>
>> This usually occurs when attempting to build 64-bit OpenSSL using the
>> 32-bit VisualStudio tools.
>>
>> Matt
>>
>>
>>
>>> Could Not Find
>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>> Stop.
>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>> : return code '0x2'
>>> Stop.
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>> Caswell
>>> Sent: Thursday, June 25, 2020 12:15 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>> From: openssl-users [[hidden email]] On Behalf
>>> Of [hidden email]
>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>
>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>> operable program or batch file.
>>>>
>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>
>>> Note that using masm to compile OpenSSL is no longer supported by us
>>> (although it might still work).
>>>
>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>
>>> If you use the Developer Studio command prompt (64-bit) it should have
>>> all the environment variables set up already to find the various VS tools.
>>>
>>> Matt
>>>
>>>
>>>>
>>>>> Building with Visual Studio  2019 Community
>>>>
>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>> maybe it's part of some optional component?
>>>>
>>>> In VS2017 Professional, which is what I have configured at the moment on
>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>> to VS's gratuitously complicated directory layout.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Error building OpenSSL-1.1.1g

Matt Caswell-2
In reply to this post by Matt Caswell-2


On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> ******************************************************************************
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> ******************************************************************************
>
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
>
> Maybe we should add an FAQ section of common faults and how to fix them.
>
> Matt
>
>
>
>
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> ----------------------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, [hidden email] wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks.
>>>
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, [hidden email] wrote:
>>>> Thanks! That helped, but I have two follow-ups.
>>>>
>>>> 1) To whom would I suggest minor changes to the available installation
>>>> instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
>>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>>> 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
>>>> Could Not Find
>>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>>> Stop.
>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>>> : return code '0x2'
>>>> Stop.
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>>> Caswell
>>>> Sent: Thursday, June 25, 2020 12:15 PM
>>>> To: [hidden email]
>>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>>
>>>>
>>>>
>>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>>> Of [hidden email]
>>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>>
>>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>
>>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>>
>>>> Note that using masm to compile OpenSSL is no longer supported by us
>>>> (although it might still work).
>>>>
>>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>>
>>>> If you use the Developer Studio command prompt (64-bit) it should have
>>>> all the environment variables set up already to find the various VS tools.
>>>>
>>>> Matt
>>>>
>>>>
>>>>>
>>>>>> Building with Visual Studio  2019 Community
>>>>>
>>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>>> maybe it's part of some optional component?
>>>>>
>>>>> In VS2017 Professional, which is what I have configured at the moment on
>>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>>> to VS's gratuitously complicated directory layout.
>>>>>
>>>>> --
>>>>> Michael Wojcik
>>>>> Distinguished Engineer, Micro Focus
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
Sadly, I'm pretty sure MSYS2 comes without perl.  At any rate, without some PATH element that has a perl, MSYS2 can't find one.

It has been a while since I installed MSYS2, and I no longer recall (or have good enough notes) whether I made a poor choice at installation time - but I can check that out.

Mike

-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 9:56 AM
To: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> ******************************************************************************
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> ******************************************************************************
>
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
>
> Maybe we should add an FAQ section of common faults and how to fix them.
>
> Matt
>
>
>
>
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> ----------------------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, [hidden email] wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks.
>>>
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, [hidden email] wrote:
>>>> Thanks! That helped, but I have two follow-ups.
>>>>
>>>> 1) To whom would I suggest minor changes to the available installation
>>>> instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
>>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>>> 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
>>>> Could Not Find
>>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>>> Stop.
>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>>> : return code '0x2'
>>>> Stop.
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>>> Caswell
>>>> Sent: Thursday, June 25, 2020 12:15 PM
>>>> To: [hidden email]
>>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>>
>>>>
>>>>
>>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>>> Of [hidden email]
>>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>>
>>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>
>>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>>
>>>> Note that using masm to compile OpenSSL is no longer supported by us
>>>> (although it might still work).
>>>>
>>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>>
>>>> If you use the Developer Studio command prompt (64-bit) it should have
>>>> all the environment variables set up already to find the various VS tools.
>>>>
>>>> Matt
>>>>
>>>>
>>>>>
>>>>>> Building with Visual Studio  2019 Community
>>>>>
>>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>>> maybe it's part of some optional component?
>>>>>
>>>>> In VS2017 Professional, which is what I have configured at the moment on
>>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>>> to VS's gratuitously complicated directory layout.
>>>>>
>>>>> --
>>>>> Michael Wojcik
>>>>> Distinguished Engineer, Micro Focus
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: 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

Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
In reply to this post by Matt Caswell-2
Thank you both, Matt and Sergio (and maybe Michael who just now weighed in but whose post I have not read).  You finally gave me clues sufficient to solve my problems. At present, OpenSSL is crunching through its tests and hasn't turned up a problem, so I think I can safely declare victory.

Thanks in particular to Sergio for giving me the assurance that OpenSSL *could* successfully build under Mingw-w6.
And thanks in particular to Matt for the key question that "It may well be that your MSYS2 environment already has perl available".

I simply re-installed MSYS2 and that solved all problem of which I was aware.

More complete response: I was running msys2-x86_64-20180531.exe, which I installed about 2 years ago.  Id *did not* include a version of perl.  It is hard to believe I would have deleted it, because that is a tool I use very frequently (though I'm generally in a standard windows command shell instead of MSYS2).  At some point, I installed and have relied on ActivePerl.

I deleted that version of MSYS2 and installed  msys2-base-x86_64-20200602.  This was a raw install - I still need to re-configure a bunch of add-on packages, but that is for later.  First thing I did after MSYS2 configured itself was re-run my build script - didn't change anything, just re-ran it.

Problem solved.

Again, thanks for sticking we me to success!

Mke


-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
Sent: Friday, June 26, 2020 9:56 AM
To: [hidden email]
Subject: Re: Error building OpenSSL-1.1.1g



On 26/06/2020 14:30, Matt Caswell wrote:
>> C:\Perl64\bin\perl.exe

Try *removing* this perl from your %PATH%. It may well be that your
MSYS2 environment already has perl available but this version is taking
priority.

Matt



>> $ perl Configure mingw --prefix=$PREFIX
>> ******************************************************************************
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
>>
>> This Perl version: 5.24.3 for MSWin32-x64-multi-thread
>> ******************************************************************************
>
> For msys2 based builds you must use the msys2 provided perl version, not
> a native perl. Make sure msys2 has the perl package installed and remove
> this one from your path.
>
> Maybe we should add an FAQ section of common faults and how to fix them.
>
> Matt
>
>
>
>
>> Configuring OpenSSL version 1.1.1g (0x1010107fL) for mingw
>> Using os-specific seed configuration
>> ----------------------------------------------------------------------------------
>>
>>
>> -----Original Message-----
>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>> Sent: Friday, June 26, 2020 3:04 AM
>> To: [hidden email]
>> Subject: Re: Error building OpenSSL-1.1.1g
>>
>>
>>
>> On 26/06/2020 00:47, [hidden email] wrote:
>>> 1. How do I figure out whether OpenSSL is trying to build the 32- or 64-bit version and which options, or environmental variables, or specific PATH elements do I need to pay attention to in order to accomplish that?
>>
>> My windows environment died on my recently, so I can't check the actual
>> output. IIRC just typing "cl" at the command line should give you
>> details about the compiler being used and whether it is for 32 or 64 bits.
>>
>> Visual Studio has a number of "developer command prompts" available with
>> it. If you start one of those it should have all the right environment
>> variables set up for you. There should be different command prompts for
>> 32 bit vs 64 bit.
>>
>> https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs
>>
>> Alternatively there is the vcvarsall.bat script which comes with VS that
>> enables you to setup all the environment variables - you can specify as
>> an argument to script whether you are targeting 32 bit or 64 bit.
>>
>> https://stackoverflow.com/questions/43372235/vcvarsall-bat-for-visual-studio-2017
>>
>> As well as the VS tools environment variables you will need to make sure
>> both Perl (e.g. Strawberry Perl) and NASM are installed and are on your
>> %PATH%.
>>
>>
>>>
>>> 2. Has anyone succeeded building OpenSSL for use in a Windows 10 environment *without* need for visual studio?
>>
>> You can do this using the MinGW compilers and the MSys2 shell. Note the
>> MinGW compilers target *native* windows. So although you use Msys2 to
>> build it, the resulting binaries are fully native.
>>
>>
>> There are details in the newly rewritten instructions for Windows:
>>
>> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/NOTES.WIN
>>
>> Matt
>>
>>
>>>
>>> I'd really appreciate any useful information or pointers to such.
>>>
>>> Thanks.
>>>
>>>
>>> -----Original Message-----
>>> From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
>>> Sent: Thursday, June 25, 2020 2:03 PM
>>> To: [hidden email]
>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>
>>>
>>>
>>> On 25/06/2020 20:20, [hidden email] wrote:
>>>> Thanks! That helped, but I have two follow-ups.
>>>>
>>>> 1) To whom would I suggest minor changes to the available installation
>>>> instructions to help avoid future such misunderstandings?
>>>
>>> You can raise on issue on Github. Or even better raise a PR with your
>>> suggested changes. However, as it so happens the Windows instructions
>>> have very recently been significantly updated - so some of your
>>> suggestions may already have been included:
>>>
>>> https://github.com/openssl/openssl/pull/12098
>>>
>>>> crypto\aes\aesni-mb-x86_64.obj : fatal error LNK1112: module machine type
>>>> 'x64' conflicts with target machine type 'x86'
>>>
>>> This usually occurs when attempting to build 64-bit OpenSSL using the
>>> 32-bit VisualStudio tools.
>>>
>>> Matt
>>>
>>>
>>>
>>>> Could Not Find
>>>> c:\Users\Owner\LocalPrograms\OpenSSL\openssl-1.1.1g\libcrypto-1_1-x64.*
>>>> NMAKE : fatal error U1077: 'link' : return code '0x1'
>>>> Stop.
>>>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>>>> Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\HostX86\x86\nmake.exe"'
>>>> : return code '0x2'
>>>> Stop.
>>>>
>>>> -----Original Message-----
>>>> From: openssl-users <[hidden email]> On Behalf Of Matt
>>>> Caswell
>>>> Sent: Thursday, June 25, 2020 12:15 PM
>>>> To: [hidden email]
>>>> Subject: Re: Error building OpenSSL-1.1.1g
>>>>
>>>>
>>>>
>>>> On 25/06/2020 18:32, Michael Wojcik wrote:
>>>>>> From: openssl-users [mailto:[hidden email]] On Behalf
>>>> Of [hidden email]
>>>>>> Sent: Thursday, June 25, 2020 11:54
>>>>>
>>>>>> Error:  'ml64' is not recognized as an internal or external command,
>>>>>> operable program or batch file.
>>>>>
>>>>> It's part of Visual C. The VC-WIN64A-masm configuration
>>>> (Configurations/50-masm.conf) specifies it as the assembler.
>>>>
>>>> Note that using masm to compile OpenSSL is no longer supported by us
>>>> (although it might still work).
>>>>
>>>> Preferred is to use the VC-WIN64A target and the nasm compiler.
>>>>
>>>> If you use the Developer Studio command prompt (64-bit) it should have
>>>> all the environment variables set up already to find the various VS tools.
>>>>
>>>> Matt
>>>>
>>>>
>>>>>
>>>>>> Building with Visual Studio  2019 Community
>>>>>
>>>>> Maybe VS2019 Community doesn't include the assembler? I haven't looked. Or
>>>> maybe it's part of some optional component?
>>>>>
>>>>> In VS2017 Professional, which is what I have configured at the moment on
>>>> this machine, it's in .../VC/Tools/MSVC/14.16.27023/bin/HostX86/x64, thanks
>>>> to VS's gratuitously complicated directory layout.
>>>>>
>>>>> --
>>>>> Michael Wojcik
>>>>> Distinguished Engineer, Micro Focus
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
In reply to this post by Michael Wojcik

Thank you very much.  While my problem has already been resolved,
you raise a couple of issues that are worth noting for
completeness.

> > 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.
>
*** snip ***
>
> My suggestion: Follow the recommended process by installing nasm
> (it's free) and configuring for that instead of MASM.

Did that as soon I decided to give up on mingw64 and try Visual
Studio.  Granted, my Y-chromosome does give me some challenges
when it comes to reading/following instructions, but that
requirement was clearly enough stated that I noticed and followed
up on it :)

> 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.

Actualy repeated that step several times throughout to ensure I
was always starting clean.

> 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".

What cl.exe responded was what I expected, so didn't report it:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe

It is still a mystery why/how anything related to 32-bit ever arose in the build process.  But I no longer care because it was apparently self-inflicted and not likely to bother anyone else.

*** snip ***

> Regarding MSYS2 and Perl:
>
> - Did you read the updated NOTES.WIN that Matt posted a link to?

Yes, found them at the beginning of my efforts, but (in case you
know the old joke about magicians), "the rabbit was already in
the hat" by that point.

*** snip ***

> - You haven't told us what Perl implementation you're
>   using.

My initial post:
   Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

>   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 think he did tell is - implicitly.  He used whatever he has
installed with his MSYS2 package.  If I'd had the same one
installed with my package, I'd have missed all this fun.
>
> - 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.

This is actually an important question.  In response to Matt's
suggestion, I went to MSYS2 to see what packages they have.
Their list of packages *did not* include a choice like "the one
we include with our initial installation in case you have somehow
lost it". Instead, they list the two give in one of my more
recent posts.  One listed is explicitly designed for use with
mingw-64.  It fails for OpenSSL the same way as ActivePerl.

Bottom line:  MSYS2 *does* include perl in its basic installation
(at least the most recent version) and it works.  Don't mess that
one up or your in for some fun.

Thanks to all.


-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Michael Wojcik
Sent: Friday, June 26, 2020 11:25 AM
To: [hidden email]
Subject: RE: Error building OpenSSL-1.1.1g

[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


Reply | Threaded
Open this post in threaded view
|

RE: Error building OpenSSL-1.1.1g

mhkelley2017
Two follow-up issues - someone please tell me if I should have started a new thread - these are not really related to the initial point of this one.

While my build and test worked after re-installing MSYS2, the install failed.  Unfortunately I inadvertently over-wrote the logfile I was keeping about this thread.

1) OPENSSLDIR was not correctly set.  In essence, while the documentation leads one to assume that the configure option --openssldir is derived from --prefix, this was NOT the case.  All of the installs went into the PREFIX I had passed to Configure until something barfed when it tried to write to c:\Program Files\SSL.  I then re-configured/re-built with both --prefix=PREFIX and --openssldir=PReFIX/SSL specified.  This seems to have worked correctly, with the relevant files then being put where they should be.

Perhaps this should be reported as a possible bug in the build process?

2) The documentation was not successfully installed.  There appears to be a complete file tree for it, but all of the html files are empty.  The failure is:

/c/usr/local/OPENSSL/openssl-1.1.1g/x86_64-8.1.0-posix-seh-rt_v6-rev0/share/doc/openssl/html/man7/X448.html -> /c/usr/local/OPENSSL/openssl-1.1.1g/x86_64-8.1.0-posix-seh-rt_v6-rev0/share/doc/openssl/html/man7/X25519.html
sh: pod2html: command not found

pod2html is a perl script in C:\msys64\usr\bin\core_perl.  I added that to my PATH.

Because I never saw any suggestion to do so, this might also be more appropriately submitted as a potential bug in the build process.



-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: Friday, June 26, 2020 12:09 PM
To: [hidden email]
Cc: 'Michael Wojcik' <[hidden email]>
Subject: RE: Error building OpenSSL-1.1.1g


Thank you very much.  While my problem has already been resolved,
you raise a couple of issues that are worth noting for
completeness.

> > 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.
>
*** snip ***
>
> My suggestion: Follow the recommended process by installing nasm
> (it's free) and configuring for that instead of MASM.

Did that as soon I decided to give up on mingw64 and try Visual
Studio.  Granted, my Y-chromosome does give me some challenges
when it comes to reading/following instructions, but that
requirement was clearly enough stated that I noticed and followed
up on it :)

> 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.

Actualy repeated that step several times throughout to ensure I
was always starting clean.

> 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".

What cl.exe responded was what I expected, so didn't report it:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\bin\Hostx86\x86\cl.exe

It is still a mystery why/how anything related to 32-bit ever arose in the build process.  But I no longer care because it was apparently self-inflicted and not likely to bother anyone else.

*** snip ***

> Regarding MSYS2 and Perl:
>
> - Did you read the updated NOTES.WIN that Matt posted a link to?

Yes, found them at the beginning of my efforts, but (in case you
know the old joke about magicians), "the rabbit was already in
the hat" by that point.

*** snip ***

> - You haven't told us what Perl implementation you're
>   using.

My initial post:
   Perl: ActivePerl 5.24.3 Build_2404 (64-bit)

>   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 think he did tell is - implicitly.  He used whatever he has
installed with his MSYS2 package.  If I'd had the same one
installed with my package, I'd have missed all this fun.
>
> - 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.

This is actually an important question.  In response to Matt's
suggestion, I went to MSYS2 to see what packages they have.
Their list of packages *did not* include a choice like "the one
we include with our initial installation in case you have somehow
lost it". Instead, they list the two give in one of my more
recent posts.  One listed is explicitly designed for use with
mingw-64.  It fails for OpenSSL the same way as ActivePerl.

Bottom line:  MSYS2 *does* include perl in its basic installation
(at least the most recent version) and it works.  Don't mess that
one up or your in for some fun.

Thanks to all.


-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Michael Wojcik
Sent: Friday, June 26, 2020 11:25 AM
To: [hidden email]
Subject: RE: Error building OpenSSL-1.1.1g

[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