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

[Andy Polyakov via RT]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: RT4289.diff
Type: text/x-patch
Size: 6663 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160203/19cfd3e5/attachment.bin>