VS 17.4 upgrade causes linker problems building TorchSharp

[NiklasGustafsson]

Upgrading to v17.4 of Visual Studio leads to a C++ compiler bug that has yet to be fixed. Solutions include using a pre-17.4 version of VS, or modifying a header file in the PyTorch Distribution as described herein:

https://stackoverflow.com/questions/74366357/updating-to-visual-studio-17-4-0-yields-linker-errors-related-to-tls

This is a C++ compiler bug, combined with a particular code pattern used in a PyTorch distribution header file, so there is nothing to do in the TorchSharp code base besides tracking it.

@GeorgeS2019, I believe you ran into this issue some time ago.

[NiklasGustafsson]

Here are the steps to hacking the header file locally:

dotnet build

This will lead to linker errors building the native library. Open the header file 'Parallel.h' under the

bin\obj\AnyCPU.Debug\libtorch-cpu\libtorch-win-shared-with-deps-debug-1.13.0cpu\libtorch\include\ATen bin\obj\AnyCPU.Debug\libtorch-cuda-11.7\libtorch-win-shared-with-deps-debug-1.13.0cu117\libtorch\include\ATen

folders. (Obviously, replace AnyCPU.Debug with AnyCPU.Release for release builds.) The file occurs twice.

In the Parallel.h header file, replace the code on line 32:

inline TORCH_API void lazy_init_num_threads() {
  thread_local bool init = false;
  if (C10_UNLIKELY(!init)) {
    at::init_num_threads();
    init = true;
  }
}

with:

TORCH_API void lazy_init_num_threads();

The .obj files have already been built, so issuing dotnet build again will just try to re-link them. You need to get rid of them by manually deleting them. This is easiest done by using a CMD shell (not PowerShell):

del /s *.obj

At this point, dotnet build should complete and you should be able to load the solution in VS using devenv TorchSharp.sln again.

[GeorgeS2019]

@NiklasGustafsson It would be great to share in e.g. readme. md which VS2022 version you use which gives you the problem and which does not have a build issue.

[NiklasGustafsson]

I've updated DEVGUIDE.md to reflect this problem. I also changed the Azure Pipelines definition to use windows-2019 instead of windows-2022, since the older VM image uses VS 16.3, which does not have this bug.

[GeorgeS2019]

@NiklasGustafsson
Using VS2022 Community (17.4.2) version with only c++ support,

MSBuild version 17.3.2+561848881 for .NET

I replaced as stated above

TORCH_API void lazy_init_num_threads();

I also make sure I have only one installation of cmake provided by VS2022 Community

There is no NON-VS2022 installed cmake!

Only that I can compile

[MovGP0]

I can reproduce the issue with JetBrains Raider (v2022.2.4) and builds using dotnet build (ie. dotnet build /p:SkipCuda=true /p:SkipNetFxBuild=true -c Debug).

The newer MSVC-Compiler might cause the issue here.

Console output

Link:
    C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\HostX64\x64\link.exe

snipped for brevity

       Creating library C:/Users/movgp/TorchSharp/bin/obj/x64.Debug/Native/LibTorchSharp/Debug/LibTorchSharp.lib and ob
  ject C:/Users/movgp/TorchSharp/bin/obj/x64.Debug/Native/LibTorchSharp/Debug/LibTorchSharp.exp
THSTorch.obj : error LNK2001: unresolved external symbol __imp___tls_index_?init@?1??lazy_init_num_threads@internal@at@
@YAXXZ@4_NA [C:\Users\movgp\TorchSharp\bin\obj\x64.Debug\Native\LibTorchSharp\LibTorchSharp.vcxproj] [C:\Users\movgp\To
rchSharp\src\Native\build.proj]

snipped for brevity

C:\Users\movgp\TorchSharp\bin\obj\x64.Debug\Native\LibTorchSharp\Debug\LibTorchSharp.dll : fatal error LNK1120: 2 unres
olved externals [C:\Users\movgp\TorchSharp\bin\obj\x64.Debug\Native\LibTorchSharp\LibTorchSharp.vcxproj] [C:\Users\movg
p\TorchSharp\src\Native\build.proj]
  Done Building Project "C:\Users\movgp\TorchSharp\bin\obj\x64.Debug\Native\LibTorchSharp\LibTorchSharp.vcxproj" (defau
  lt targets) -- FAILED.
  Done Building Project "C:\Users\movgp\TorchSharp\bin\obj\x64.Debug\Native\ALL_BUILD.vcxproj" (default targets) -- FAI
  LED.
  Done Building Project "C:\Users\movgp\TorchSharp\bin\obj\x64.Debug\Native\INSTALL.vcxproj" (build target(s)) -- FAILE
  D.

  Build FAILED.

Notes

The build in Azure uses a slightly older linker:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\link.exe

[NiklasGustafsson]

@MovGP0 -- yes, the 14.34,31933 compiler is the one that has the bug. I had to revert the CI/CD build to use VS 2019 in order to get an old enough version for it to work. If you can find a 14.33.XXX version on your system, that should work.

[MovGP0]

If you can find a 14.33.XXX version on your system, that should work.

currently I have the following versions:

• VS 2019 Build Tools in
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\link.exe
• VS 2022 Build Tools in
  C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\Hostx64\x64\link.exe

However, I am currently unsure how to change the path for the build.

My workaround is commenting the following lines in \TorchSharp\src\Native\build.cmd:

:: Setup vars for VS2022
set __PlatformToolset=v143
set __VSVersion=17 2022
if NOT "%__BuildArch%" == "arm64" (
    :: Set the environment for the native build
    call "%VS160COMNTOOLS%..\..\VC\Auxiliary\Build\vcvarsall.bat" %__VCBuildArch%
)
goto :SetupDirs

This way the older compiler will be used. Also needed to clean the temporary files from cmake:

git clean -xfd
dotnet build /p:SkipCuda=true /p:SkipNetFxBuild=true -c Debug

[NiklasGustafsson]

I received word that this bug had been fixed in 17.4.3.

[MovGP0]

I am currently on 17.4.4 and still experiencing issues

[ChengYen-Tang]

This issue has been fixed in 17.5

[NiklasGustafsson]

@MovGP0 -- do you still have problems with this, or can we close the issue?