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