Zitat von Andy Polyakov via RT < <mailto:r...@openssl.org> 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