Hi, Something may be wrong, but I'm not sure. At least te output below gives some confusion regarding possible errors. See transcript below. The Operating system is Windows XP, the compiler is visual studio 2005 SP1. The necessary steps to build openSSL are performed as custom build step from within visual studio 2005.
Based on the transcript:
Two confusing things popup when do_ms.bat is called (by our build, from within
visual studio 2005):
a. message: unknown option 'enable-threads'.
Although configure was called with the 'threads' option,the resulting
'enable-threads' was not understood by the util\mk1mf.pl perl file. This error
message is probably harmless (?), but can be fixed if the option is added to
util\mk1mf.pl file list of known options.
b. message: usage: cl.exe ...
This message only happens when calling do_ms.bat from within visual studio 2005
as custom build step. When calling do_ms.bat from the visual studio command
prompt, the problem did not appear. After some research, line:
$ex_libs.=' bufferoverflowu.lib' if ($FLAVOR =~ /WIN64/ and `cl 2>&1` =~
/14\.00\.4[0-9]{4}\./);
in util\pl\vc-32.pl (around line 169), causes the usage output of cl, but only
when called from within visual studio. When it is called from within visual
studio, and the output is shown in the visual studio output, then the check on
the version will fail, because the backtick command results an empty string.
This can be quite easily tested by catching the output of `cl 2>&1` in a
variable and writing the output to STDERR (STDERR is not catches in do_ms.bat).
However, I really don't know how to make a fix. For some reason, visual studio
2005 is changing the way how stderr/stdout are redirected. I tested several
constructs in perl to catch the version information (like open $fh, "cl.exe
2>&1 |", or `cmd /c cl.exe 2>&1` etc), but no one works. Of course these
examples work when called from a CMD.exe window :(. I tried with ml64.exe, but
ml64.exe works fine (i.e. the output can be catched fine, both from cmd.exe as
well from within visual studio 2005). But, finally, the output is used to add
bufferoverflowu.lib, which is not existent anymore in the Windows 2008 platform
SDK (=v6.1).
So I would like to propose:
Either replace the check of cl.exe on link.exe by something else or remove the
check, and do not add bufferoverflowu.lib. See also
http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/fc6d520c-d53b-4309-8f5e-76be3f0e2b73
for more information.
Just my 2 cents: the check on a version of any tool of visual studio 2005 is
not 100% bulletproof. Actually, you like to check on the existence of a certain
library (but also dependent on used compiler flags). It may be worth to check
whether the values of the environment variables LIB, or LIBPATH can be used for
that purpose (and check whether Platform SDK v5 was used/bufferoverflowu.lib
was existent)? The delivered platform SDK together with Visual Studio 2005 has
bufferoverflowu.lib as separate library (the %VSINSTALLDIR%\ VC\PlatformSDK\Lib
(or similar path for AMD64). The path should then part of the LIB and/or
LIBPATH. The Windows 2008 Platform SDK works well with Visual Studio 2005, but
this SDK does not have bufferoverflowu.lib anymore (i.e. no V6.x Platform SDK
has this lib anymore). May be the lib.exe tool can be used to figure out
whether a path to bufferoverflowu.lib can be used. And worst case, you may need
to write a test makefile whether a small program will bu
ild with bufferoverflowu.lib in the path. Anyhow, Visual Studio 2005 gets out
of support by Microsoft, and Visual Studio 2008/2010 are already successor
versions. Therefore, you may decide to drop the whole bufferoverflowu.lib line
at all.
If you like, I can provide a simple reproduction (one .sln file for visual
studio 2005 + a vcproj file + some other files) to see that calling cl.exe from
a batch file or perl script does not catch any output of cl.exe, when called
from within visual studio 2005.
Regards,
Kees
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl
p:\common\thirdparty\OpenSSL\PerlRun.pl
"p:\obj.winx64\thirdparty\openssl\openssl-1.0.0d\Configure" VC-WIN64A no-asm
no-shared threads -DWINVER=0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS
--prefix=\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d
2>ccperl p:/obj.winx64/thirdparty/openssl/openssl-1.0.0d/Configure VC-WIN64A
no-asm no-shared threads -DWINVER=0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS
--prefix=/obj.WINx64/thirdparty/OpenSSL/openssl-1.0.0d
2>Configuring for VC-WIN64A
2> no-asm [option] OPENSSL_NO_ASM
2> no-gmp [default] OPENSSL_NO_GMP (skip dir)
2> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
2> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
2> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
2> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
2> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
2> no-shared [option]
2> no-store [experimental] OPENSSL_NO_STORE (skip dir)
2> no-zlib [default]
2> no-zlib-dynamic [default]
2>IsMK1MF=1
2>CC =cl
2>CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -DWINVER=0x0501
-D_CRT_NON_CONFORMING_SWPRINTFS -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE
2>EX_LIBS =
2>CPUID_OBJ =mem_clr.o
2>BN_ASM =bn_asm.o
2>DES_ENC =des_enc.o fcrypt_b.o
2>AES_ENC =aes_core.o aes_cbc.o
2>BF_ENC =bf_enc.o
2>CAST_ENC =c_enc.o
2>RC4_ENC =rc4_enc.o rc4_skey.o
2>RC5_ENC =rc5_enc.o
2>MD5_OBJ_ASM =
2>SHA1_OBJ_ASM =
2>RMD160_OBJ_ASM=
2>CMLL_ENC= =camellia.o cmll_misc.o cmll_cbc.o
2>PROCESSOR =
2>RANLIB =true
2>ARFLAGS =
2>PERL =ccperl
2>SIXTY_FOUR_BIT mode
2>DES_INT used
2>RC4_CHUNK is unsigned long long
2>Configured for VC-WIN64A.
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>if errorlevel 1
2>Replacing perl by ccperl in bat and cmd files
2>Current working directory is P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>if "x64" == "x64" (call
ms\do_win64a.bat ) else (call ms\do_ms.bat )
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mkfiles.pl
1>MINFO
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl ms\uplink.pl win64a
1>ms\uptable.asm
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ml64 -c -Foms\uptable.obj
ms\uptable.asm
2> Assembling: ms\uptable.asm
2>Microsoft (R) Macro Assembler (x64) Version 8.00.50727.762
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mk1mf.pl no-asm
VC-WIN64A 1>ms\nt.mak
2>unknown option - enable-threads
2>Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>usage: cl [ option... ] filename... [ /link linkoption... ]
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mk1mf.pl dll
no-asm VC-WIN64A 1>ms\ntdll.mak
2>unknown option - enable-threads
2>Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>usage: cl [ option... ] filename... [ /link linkoption... ]
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mkdef.pl 32
libeay 1>ms\libeay32.def
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mkdef.pl 32
ssleay 1>ms\ssleay32.def
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>echo Error = 0
2>Error = 0
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>if errorlevel 1 goto error
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>echo Error2 = 0
2>Error2 = 0
2>Replacing perl by ccperl in .mak files
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>nmake -f ms\ntdll.mak
2>Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>Building OpenSSL
2> ccperl util/mkdir-p.pl "tmp32dll"
Hi,
Something may be wrong, but I’m not sure. At least te output below gives some confusion regarding possible errors. See transcript below. The Operating system is Windows XP, the compiler is visual studio 2005 SP1. The necessary steps to build openSSL are
performed as custom build step from within visual studio 2005.
Based on the transcript:
Two confusing things popup when do_ms.bat is called (by our build, from within visual studio 2005):
- message: unknown option ‘enable-threads’.
Although configure was called with the ‘threads’ option,the resulting ‘enable-threads’ was not understood by the util\mk1mf.pl perl file. This error message is probably harmless (?), but can be fixed if the option is added to util\mk1mf.pl file list of known options. - message: usage: cl.exe …
This message only happens when calling do_ms.bat from within visual studio 2005 as custom build step. When calling do_ms.bat from the visual studio command prompt, the problem did not appear. After some research, line:
$ex_libs.=' bufferoverflowu.lib' if ($FLAVOR =~ /WIN64/ and `cl 2>&1` =~ /14\.00\.4[0-9]{4}\./);
in util\pl\vc-32.pl (around line 169), causes the usage output of cl, but only when called from within visual studio. When it is called from within visual studio, and the output is shown in the visual studio output, then the
check on the version will fail, because the backtick command results an empty string.
This can be quite easily tested by catching the output of `cl 2>&1` in a variable and writing the output to STDERR (STDERR is not catches in do_ms.bat). However, I really don’t know how to make a fix. For some reason, visual
studio 2005 is changing the way how stderr/stdout are redirected. I tested several constructs in perl to catch the version information (like open $fh, “cl.exe 2>&1 |”, or `cmd /c cl.exe 2>&1` etc), but no one works. Of course these examples work when called
from a CMD.exe window L. I tried with ml64.exe, but ml64.exe works fine (i.e. the output can be catched fine, both from cmd.exe as well from within visual studio 2005). But, finally, the output is used to add bufferoverflowu.lib,
which is not existent anymore in the Windows 2008 platform SDK (=v6.1).
So I would like to propose:
Either replace the check of cl.exe on link.exe by something else or remove the check, and do not add bufferoverflowu.lib. See also http://social.msdn.microsoft.com/Forums/en/vcgeneral/thread/fc6d520c-d53b-4309-8f5e-76be3f0e2b73
for more information.
Just my 2 cents: the check on a version of any tool of visual studio 2005 is not 100% bulletproof. Actually, you like to check on the existence of a certain library (but also dependent on used compiler flags). It may be worth to check whether the values
of the environment variables LIB, or LIBPATH can be used for that purpose (and check whether Platform SDK v5 was used/bufferoverflowu.lib was existent)? The delivered platform SDK together with Visual Studio 2005 has bufferoverflowu.lib as separate library
(the %VSINSTALLDIR%\ VC\PlatformSDK\Lib (or similar path for AMD64). The path should then part of the LIB and/or LIBPATH. The Windows 2008 Platform SDK works well with Visual Studio 2005, but this SDK does not have bufferoverflowu.lib anymore (i.e. no V6.x
Platform SDK has this lib anymore). May be the lib.exe tool can be used to figure out whether a path to bufferoverflowu.lib can be used. And worst case, you may need to write a test makefile whether a small program will build with bufferoverflowu.lib in the
path. Anyhow, Visual Studio 2005 gets out of support by Microsoft, and Visual Studio 2008/2010 are already successor versions. Therefore, you may decide to drop the whole bufferoverflowu.lib line at all.
If you like, I can provide a simple reproduction (one .sln file for visual studio 2005 + a vcproj file + some other files) to see that calling cl.exe from a batch file or perl script does not catch any output of cl.exe, when called from within visual studio
2005.
Regards,
Kees
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl p:\common\thirdparty\OpenSSL\PerlRun.pl "p:\obj.winx64\thirdparty\openssl\openssl-1.0.0d\Configure" VC-WIN64A no-asm no-shared threads -DWINVER=0x0501
-D_CRT_NON_CONFORMING_SWPRINTFS --prefix=\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d
2>ccperl p:/obj.winx64/thirdparty/openssl/openssl-1.0.0d/Configure VC-WIN64A no-asm no-shared threads -DWINVER=0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS --prefix=/obj.WINx64/thirdparty/OpenSSL/openssl-1.0.0d
2>Configuring for VC-WIN64A
2> no-asm [option] OPENSSL_NO_ASM
2> no-gmp [default] OPENSSL_NO_GMP (skip dir)
2> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
2> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
2> no-md2 [default] OPENSSL_NO_MD2 (skip dir)
2> no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
2> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
2> no-shared [option]
2> no-store [experimental] OPENSSL_NO_STORE (skip dir)
2> no-zlib [default]
2> no-zlib-dynamic [default]
2>IsMK1MF=1
2>CC =cl
2>CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -DWINVER=0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE
2>EX_LIBS =
2>CPUID_OBJ =mem_clr.o
2>BN_ASM =bn_asm.o
2>DES_ENC =des_enc.o fcrypt_b.o
2>AES_ENC =aes_core.o aes_cbc.o
2>BF_ENC =bf_enc.o
2>CAST_ENC =c_enc.o
2>RC4_ENC =rc4_enc.o rc4_skey.o
2>RC5_ENC =rc5_enc.o
2>MD5_OBJ_ASM =
2>SHA1_OBJ_ASM =
2>RMD160_OBJ_ASM=
2>CMLL_ENC= =camellia.o cmll_misc.o cmll_cbc.o
2>PROCESSOR =
2>RANLIB =true
2>ARFLAGS =
2>PERL =ccperl
2>SIXTY_FOUR_BIT mode
2>DES_INT used
2>RC4_CHUNK is unsigned long long
2>Configured for VC-WIN64A.
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>if errorlevel 1
2>Replacing perl by ccperl in bat and cmd files
2>Current working directory is P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>if "x64" == "x64" (call ms\do_win64a.bat ) else (call ms\do_ms.bat )
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mkfiles.pl 1>MINFO
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl ms\uplink.pl win64a 1>ms\uptable.asm
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ml64 -c -Foms\uptable.obj ms\uptable.asm
2> Assembling: ms\uptable.asm
2>Microsoft (R) Macro Assembler (x64) Version 8.00.50727.762
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mk1mf.pl no-asm VC-WIN64A 1>ms\nt.mak
2>unknown option - enable-threads
2>Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>usage: cl [ option... ] filename... [ /link linkoption... ]
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mk1mf.pl dll no-asm VC-WIN64A 1>ms\ntdll.mak
2>unknown option - enable-threads
2>Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>usage: cl [ option... ] filename... [ /link linkoption... ]
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mkdef.pl 32 libeay 1>ms\libeay32.def
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>ccperl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>echo Error = 0
2>Error = 0
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>if errorlevel 1 goto error
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>echo Error2 = 0
2>Error2 = 0
2>Replacing perl by ccperl in .mak files
2>P:\obj.WINx64\thirdparty\OpenSSL\openssl-1.0.0d>nmake -f ms\ntdll.mak
2>Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
2>Copyright (C) Microsoft Corporation. All rights reserved.
2>Building OpenSSL
2> ccperl util/mkdir-p.pl "tmp32dll"
