diff options
| author | Daniel Podder <dpodder@gmail.com> | 2017-09-14 10:35:42 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-09-14 10:35:42 -0700 |
| commit | 6ac4c997b65d45a460368463f342477326cecd1f (patch) | |
| tree | 662dd64841d1774fa53ad697a2fa83dac949820a /build.cmd | |
| parent | b5bcc13876b31e6ab83c58e7bf362410124d681f (diff) | |
| download | coreclr-6ac4c997b65d45a460368463f342477326cecd1f.tar.gz coreclr-6ac4c997b65d45a460368463f342477326cecd1f.tar.bz2 coreclr-6ac4c997b65d45a460368463f342477326cecd1f.zip | |
PGI: Load pgort<ver>.dll from the VS native tools env; do not `install` it (#12581)
On Windows, PGO instrumented builds (build.cmd release <arch>
pgoinstrument) introduce a runtime dependency on pgort<ver>.dll for
instrumented binaries. This DLL is distributed alongside the C++
compiler, and is made available via the native tools environment that
ships with Visual Studio.
Previously, we were using cmake to find and "install" this binary
alongside the product when doing an instrumented build, so that the
resulting bin\Product drop is free of any added external dependencies.
However, this approach is fragile, and despite a best effort to make the
implementation work across multiple VS releases, it already broke with
VS 2017.
To fix support for pgoinstrument on VS 2017, and to harden the
implementation for future releases of VS, I'm removing the custom cmake
install logic for the pgort DLL. Instead, we fall back to the officially
supported method: load the correct (native tools) environment before
invoking any command that uses an instrumented binary. This happens in
one place in the build today--loading the JIT to crossgen
System.Private.CoreLib.dll.
Note that there's still an existing CLI/Setup bug that requires copying
the pgort DLL. We're now doing it from within build.cmd, which is not
nearly as fragile for this as cmake is. The workaround is also isolated,
so when the referenced issue is fixed, the workaround (as documented)
can simply be removed.
Fixes #12347.
Diffstat (limited to 'build.cmd')
| -rw-r--r-- | build.cmd | 25 |
1 files changed, 25 insertions, 0 deletions
@@ -540,6 +540,31 @@ set PATH=%PATH%;%WinDir%\Microsoft.Net\Framework64\V4.0.30319;%WinDir%\Microsoft if %__BuildNativeCoreLib% EQU 1 ( echo %__MsgPrefix%Generating native image of System.Private.CoreLib for %__BuildOS%.%__BuildArch%.%__BuildType% + REM Need VS native tools environment for the **target** arch when running instrumented binaries + if %__PgoInstrument% EQU 1 ( + set __VCExecArch=%__BuildArch% + if /i [%__BuildArch%] == [x64] set __VCExecArch=amd64 + echo %__MsgPrefix%Using environment: "%__VCToolsRoot%\vcvarsall.bat" !__VCExecArch! + call "%__VCToolsRoot%\vcvarsall.bat" !__VCExecArch! + @if defined _echo @echo on + if NOT !errorlevel! == 0 ( + echo %__MsgPrefix%Error: Failed to load native tools environment for !__VCExecArch! + goto CrossgenFailure + ) + + REM HACK: Workaround for [dotnet/coreclr#13970](https://github.com/dotnet/coreclr/issues/13970) + set __PgoRtPath= + for /f "tokens=*" %%f in ('where pgort*.dll') do ( + if not defined __PgoRtPath set "__PgoRtPath=%%~f" + ) + echo %__MsgPrefix%Copying "!__PgoRtPath!" into "%__BinDir%" + copy /y "!__PgoRtPath!" "%__BinDir%" || ( + echo %__MsgPrefix%Error: copy failed + goto CrossgenFailure + ) + REM End HACK + ) + set NEXTCMD="%__CrossgenExe%" %__IbcTuning% /Platform_Assemblies_Paths "%__BinDir%"\IL /out "%__BinDir%\System.Private.CoreLib.dll" "%__BinDir%\IL\System.Private.CoreLib.dll" echo %__MsgPrefix%!NEXTCMD! !NEXTCMD! > "%__CrossGenCoreLibLog%" 2>&1 |