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

[Dannhauer Torben via RT]

What is the status of this bug? Will it be fixed in the next release (1.0.2f 
/1.1.0) ?

Thanks,
Torben

-Ursprüngliche Nachricht-
Von: Matt Caswell via RT [mailto:r...@openssl.org] 
Gesendet: Mittwoch, 3. Februar 2016 22:48
An: Dannhauer Torben <torben.dannha...@pmu.ac.at>
Cc: openssl-dev@openssl.org
Betreff: Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in 
Win32 makefiles, easy to fix, solution provided



On 03/02/16 19:43, Salz, Rich via RT wrote:
>> The diff works perfectly on master, but exposed a new bug (bare snprintf).
>> The following patch fixes it.  I can make a PR (or add it to my 
>> existing PR #512) if you'd like.
> 
> Please do as a separate PR.  Thanks.

I think Richard is already on the case, so no need for a PR.

Matt



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Dannhauer Torben via RT]

Thanks!

-Ursprüngliche Nachricht-
Von: Salz, Rich via RT [mailto:r...@openssl.org] 
Gesendet: Donnerstag, 11. Februar 2016 09:33
An: Dannhauer Torben <torben.dannha...@pmu.ac.at>
Cc: openssl-dev@openssl.org
Betreff: RE: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in 
Win32 makefiles, easy to fix, solution provided


> What is the status of this bug? Will it be fixed in the next release (1.0.2f
> /1.1.0) ?

yes

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich via RT]

> What is the status of this bug? Will it be fixed in the next release (1.0.2f
> /1.1.0) ?

yes

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

> I verified the problem on both 1.0.2f and master:
> 
> set LINK=/DEBUG
> perl Configure VC-WIN64A
> ms\do_win64a.bat
> nmake -f ms\nt.make
> 
>  link /nologo /subsystem:console /opt:ref /debug 
> /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp
> LINK : fatal error LNK1181: cannot open input file 'link.obj'
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
> Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'

Patch is applied. Closing ticket.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell]

On 03/02/16 19:43, Salz, Rich via RT wrote:
>> The diff works perfectly on master, but exposed a new bug (bare snprintf).
>> The following patch fixes it.  I can make a PR (or add it to my existing PR 
>> #512)
>> if you'd like.
> 
> Please do as a separate PR.  Thanks.

I think Richard is already on the case, so no need for a PR.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Matt Caswell via RT]

On 03/02/16 19:43, Salz, Rich via RT wrote:
>> The diff works perfectly on master, but exposed a new bug (bare snprintf).
>> The following patch fixes it.  I can make a PR (or add it to my existing PR 
>> #512)
>> if you'd like.
> 
> Please do as a separate PR.  Thanks.

I think Richard is already on the case, so no need for a PR.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided (was: [OpenSSL Bug #2928])

[Dannhauer Torben via RT]

This bug affects 1.0.2.f and supposedly also 1.1.0 alpha, I reported it already 
3 years (!!) ago as Bug #2928 for OpenSSL 1.0.1c, but it was closed yesterday 
since 1.0.1 development is finished.

Please find attached the Bug description again for OpenSSL 1.0.2f. I provide 
already a solution, so please apply the bug fix to trunk, 1.0.2 and 1.1.0 
branches

The bug is not obvious since only few people use the MSBuild System in this 
extend. However, it is clearly defined by MS how it's build system works and 
thus why OpenSSL building fails in certain conditions.



-- BUG DESCRIPTION (Copied and updated from Bug #2928) --

Dear OpenSSL Team,

I recently tried to build OpenSSL with Visual Studio and I discovered a very 
annoying but easy to fix bug:

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:

In Visual Studio, the compiler is called cl.exe and the linker is called 
link.exe.
On invocation, they append the command line arguments to the environment 
variable identical to their name (if they exist). This allows to define 
"global" linker or compiler flags which are not part of the makefile.
On the backside this also implies that a makefile must not use internal 
variable names identical to the build systems env-vars "LINK" and "CL".

This error was observed with MS VS 2013 Update 5 but applies to older Visual 
Studios as well.



## Example with the CURRENT (WRONG) status #
Build Environment (Visual Studio Command line):
SET LINK=

Makefile of OpenSSL
SET LINK=link.exe
SET LINKER_ARGS=

The resulting linker call triggered by the makefile script is then:
$(LINK) $(LINKER_ARGS)
Which is extended by the MSVC build system to (because MSVC adds the content of 
the variable LINK after the linker command)
$(LINK) $(LINK) $(LINKER_ARGS)
and finally stripped to:
link.exe link.exe 


This is a double invocation of link.exe which causes link to try linking 
itself, which of course fails.



### CORRECTED Example #
Build Environment (Visual Studio Command line):
SET LINK=

Makefile:
SET LINKER_BIN=link.exe
SET LINKER_ARGS=

The call should be:
$(LINKER_BIN) $(LINKER_ARGS)
Which would be extended by the MSVC build system to
$(LINKER_BIN) $(LINK) $(LINKER_ARGS)
and finally be stripped to:
link.exe  

==>This would be correct and working



 How to solve it: #


- Never use the variables named LINK and CL inside the makefiles or their 
generator scripts.

- Please call the binary variables different, e.g. LINKER_BIN and COMPILER_BIN

- Adapt your build scripts to generate such corrected makefiles


Thank you for your help

Kind regards,
Torben Dannhauer

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Joey Yandle via RT]

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

cheers,

Joey


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Joey Yandle]

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?

cheers,

Joey
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

> 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





___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Joey Yandle via RT]

I verified the problem on both 1.0.2f and master:

set LINK=/DEBUG
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake -f ms\nt.make

 link /nologo /subsystem:console /opt:ref /debug 
/out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Joey Yandle]

I verified the problem on both 1.0.2f and master:

set LINK=/DEBUG
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake -f ms\nt.make

link /nologo /subsystem:console /opt:ref /debug 
/out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp

LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [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 <  r...@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

 

 

 


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Joey Yandle]

And verify attached diff and report back.


The diff works perfectly on master, but exposed a new bug (bare 
snprintf).  The following patch fixes it.  I can make a PR (or add it to 
my existing PR #512) if you'd like.


diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,

 if (BIO_do_accept(acpt) <= 0)
 goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));


 client = BIO_new_connect(addr_str);
 BIO_set_conn_ip_family(client, family);

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Joey Yandle via RT]

> And verify attached diff and report back.

The diff works perfectly on master, but exposed a new bug (bare 
snprintf).  The following patch fixes it.  I can make a PR (or add it to 
my existing PR #512) if you'd like.

diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,
  if (BIO_do_accept(acpt) <= 0)
  goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));

  client = BIO_new_connect(addr_str);
  BIO_set_conn_ip_family(client, family);


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich via RT]

> The diff works perfectly on master, but exposed a new bug (bare snprintf).
> The following patch fixes it.  I can make a PR (or add it to my existing PR 
> #512)
> if you'd like.

Please do as a separate PR.  Thanks.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [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.



diff --git a/util/mk1mf.pl b/util/mk1mf.pl
index f9eeea8..506d491 100755
--- a/util/mk1mf.pl
+++ b/util/mk1mf.pl
@@ -646,7 +646,7 @@ EX_LIBS=$ex_libs
 # The OpenSSL directory
 SRC_D=$src_dir
 
-LINK=$link
+LINK_CMD=$link
 LFLAGS=$lflags
 RSC=$rsc
 FIPSLINK=\$(PERL) util${o}fipslink.pl
diff --git a/util/pl/BC-32.pl b/util/pl/BC-32.pl
index 36ad682..364c4d4 100644
--- a/util/pl/BC-32.pl
+++ b/util/pl/BC-32.pl
@@ -142,7 +142,7 @@ ___
 		{
 		local($ex)=($target =~ /O_SSL/)?' $(L_CRYPTO)':'';
 		$ex.=' ws2_32.lib gdi32.lib';
-		$ret.="\t\$(LINK) \$(MLFLAGS) $efile$target /def:ms/${Name}.def @<<\n  \$(SHLIB_EX_OBJ) $objs $ex\n<<\n";
+		$ret.="\t\$(LINK_CMD) \$(MLFLAGS) $efile$target /def:ms/${Name}.def @<<\n  \$(SHLIB_EX_OBJ) $objs $ex\n<<\n";
 		}
 	$ret.="\n";
 	return($ret);
@@ -156,7 +156,7 @@ sub do_link_rule
 	$file =~ s/\//$o/g if $o ne '/';
 	$n=($target);
 	$ret.="$target: $files $dep_libs\n";
-	$ret.="\t\$(LINK) \$(LFLAGS) $files \$(APP_EX_OBJ), $target,, $libs\n\n";
+	$ret.="\t\$(LINK_CMD) \$(LFLAGS) $files \$(APP_EX_OBJ), $target,, $libs\n\n";
 	return($ret);
 	}
 
diff --git a/util/pl/Mingw32.pl b/util/pl/Mingw32.pl
index fe3fb27..55c85f6 100644
--- a/util/pl/Mingw32.pl
+++ b/util/pl/Mingw32.pl
@@ -98,7 +98,7 @@ sub do_link_rule
 	$file =~ s/\//$o/g if $o ne '/';
 	$n=($target);
 	$ret.="$target: $files $dep_libs\n";
-	$ret.="\t\$(LINK) ${efile}$target \$(LFLAGS) $files $libs\n\n";
+	$ret.="\t\$(LINK_CMD) ${efile}$target \$(LFLAGS) $files $libs\n\n";
 	return($ret);
 	}
 1;
diff --git a/util/pl/OS2-EMX.pl b/util/pl/OS2-EMX.pl
index 28cd116..92a332e 100644
--- a/util/pl/OS2-EMX.pl
+++ b/util/pl/OS2-EMX.pl
@@ -99,7 +99,7 @@ sub do_lib_rule
 		{
 		local($ex)=($target =~ /O_SSL/)?' $(L_CRYPTO)':'';
 		$ex.=' -lsocket';
-		$ret.="\t\$(LINK) \$(SHLIB_CFLAGS) \$(MLFLAGS) $efile$target \$(SHLIB_EX_OBJ) \$(${Name}OBJ) $ex os2/${Name}.def\n";
+		$ret.="\t\$(LINK_CMD) \$(SHLIB_CFLAGS) \$(MLFLAGS) $efile$target \$(SHLIB_EX_OBJ) \$(${Name}OBJ) $ex os2/${Name}.def\n";
 		$ret.="\temximp -o $out_def/$name.a os2/${Name}.def\n";
 		$ret.="\temximp -o $out_def/$name.lib os2/${Name}.def\n\n";
 		}
@@ -113,7 +113,7 @@ sub do_link_rule
 	$file =~ s/\//$o/g if $o ne '/';
 	$n=($target);
 	$ret.="$target: $files $dep_libs\n";
-	$ret.="\t\$(LINK) ${efile}$target \$(CFLAG) \$(LFLAGS) $files $libs\n\n";
+	$ret.="\t\$(LINK_CMD) ${efile}$target \$(CFLAG) \$(LFLAGS) $files $libs\n\n";
 	return($ret);
 	}
 
diff --git a/util/pl/VC-32.pl b/util/pl/VC-32.pl
index 73160e9..258b694 100644
--- a/util/pl/VC-32.pl
+++ b/util/pl/VC-32.pl
@@ -361,7 +361,7 @@ sub do_lib_rule
  		if ($fips && $target =~ /O_CRYPTO/)
 			{
 			$ret.="$target: $objs \$(PREMAIN_DSO_EXE)";
-			$ret.="\n\tSET FIPS_LINK=\$(LINK)\n";
+			$ret.="\n\tSET FIPS_LINK=\$(LINK_CMD)\n";
 			$ret.="\tSET FIPS_CC=\$(CC)\n";
 			$ret.="\tSET FIPS_CC_ARGS=/Fo\$(OBJ_D)${o}fips_premain.obj \$(SHLIB_CFLAGS) -c\n";
 			$ret.="\tSET PREMAIN_DSO_EXE=\$(PREMAIN_DSO_EXE)\n";
@@ -375,7 +375,7 @@ sub do_lib_rule
 		else
 			{
 			$ret.="$target: $objs";
-			$ret.="\n\t\$(LINK) \$(MLFLAGS) $efile$target $name @<<\n  \$(SHLIB_EX_OBJ) $objs $ex \$(EX_LIBS)\n<<\n";
+			$ret.="\n\t\$(LINK_CMD) \$(MLFLAGS) $efile$target $name @<<\n  \$(SHLIB_EX_OBJ) $objs $ex \$(EX_LIBS)\n<<\n";
 			}
 
 		$ret.="\tIF EXIST \$@.manifest mt -nologo -manifest \$@.manifest -outputresource:\$@;2\n\n";
@@ -393,13 +393,13 @@ sub do_link_rule
 	$ret.="$target: $files $dep_libs\n";
 	if ($standalone == 1)
 		{
-		$ret.="  \$(LINK) \$(LFLAGS) $efile$target @<<\n\t";
+		$ret.="