[openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Torben Dannhauer via RT]

Zitat von Andy Polyakov via RT < <mailto:rt at openssl.org> rt at openssl.org>:

 

> On 02/03/16 17:15, Joey Yandle via RT wrote:

>>> In the makefile created by Perl, the linker binary name is assigned 

>>> to a variable named LINK. This variable $(LINK) is called to execute 

>>> the linker call.

>>> This causes a serious collision with the MS Visual Studio build 

>>> system which also relies on a variable named LINK:

>> 

>> Are you invoking msbuild.exe to build openssl?  The supported build 

>> instructions use nmake.exe directly on the generated makefiles.

>> 

>> What is your build invocation?

> 

> That was my initial reaction too. The problem description sounds like 

> as if something else is being talked about. Indeed, it refers to SET 

> LINK=link.exe (there is not *SET* LINK in generated makefile), and you 

> can't help wondering how would such problem go unnoticed for such long 

> time. But as it turns out... Consider

> 

> FOO=bar

> 

> all:

>             echo %%FOO%%

> 

> If passed to nmake, it prints "%FOO%" as long as there is no 

> environment variable named FOO. But as soon as you assign FOO variable 

> prior invoking nmake it prints "bar" irregardless[!] FOO's original value.

> LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables 

> that can be used to specify kind of site-specific defaults. I find it 

> hard to imagine how LINK would be useful in general case, i.e. as 

> something that would be applicable to *all* linked binaries, but I 

> suppose one can't deny the option to do so. Out of curiosity what's 

> yours? And verify attached diff and report back.

 

 

 

Hi, thanks for feedback,

 

I use nmake as described in the instructions.

 

Indeed, as I discovered and reported the bug 3 years ago, my first question
was how such a problem was undiscovered for so a long time.  

At least now we are talking about it and agree we should fix it.

 

Technical details:

 

The env variable LINK is only evaluated by link.exe if it is set in the
commandline (e.g. as required for compiling WinXP compatible binaries with
VS 2012 and newer: setting another subsystem version) Since WinXP compiling
is more than only setting linker flags, we simulate it by setting instead a
empty LINK variable- the key aspect is that the COMMANDLINE has a set LINK
variable , then the LINK variable is evaluated by link.exe and the error
occurs. This happens because the OpenSSL makefile uses a also variable named
LINK.

 

To reproduce the error, open visual studio x64 commandline and enter:

 

Set link=""

perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64 ms\do_win64a nmake -f
"ms\ntdll.mak"

 

-> wait and see the linker step failing..

 

The provided patch is exactly what I did the last 3 years manually in the
ntdll.mak makefile before starting the compilation.

 

I would be very glad to see it marger into trunk.

 

regards,

Torben

 

 

PS.: The full story to compile WinXP compatible binaries on commandline in
VS2012 and newer is this:

 

------- x86 -----------------

 

@set INCLUDE=%ProgramFiles(x86)%\Microsoft
SDKs\Windows\7.1A\Include;%INCLUDE%

@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set
LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% @set
CL=/D_USING_V110_SDK71_;%CL%

 

@set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK%

 

@echo Switched to XP target x86

 

 

 

----------- x64 (WinXp x64 is quite rare)

 

@set INCLUDE=%ProgramFiles(x86)%\Microsoft
SDKs\Windows\7.1A\Include;%INCLUDE%

@set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set
LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% @set
CL=/D_USING_V110_SDK71_;%CL%

 

@set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK%

 

@echo Switched to XP target x64