Use CAFFE2_USE_MSVC_STATIC_RUNTIME to determine when to avoid waiting for global destructors on Windows #46014
Conversation
… for global destructors on Windows (pytorch#43532) Summary: We are trying to build libtorch statically (BUILD_SHARED_LIBS=OFF) then link it into a DLL. Our setup hits the infinite loop mentioned [here](https://github.com/pytorch/pytorch/blob/54c05fa34e1fbbb5096746a8ae92e27a08116de4/torch/csrc/autograd/engine.cpp#L228) because we build with `BUILD_SHARED_LIBS=OFF` but still link it all into a DLL at the end of the day. This PR fixes the issue by changing the condition to guard on which windows runtime the build links against using the `CAFFE2_USE_MSVC_STATIC_RUNTIME` flag. `CAFFE2_USE_MSVC_STATIC_RUNTIME` defaults to ON when `BUILD_SHARED_LIBS=OFF`, so backwards compatibility is maintained. I'm not entirely confident I understand the subtleties of the windows runtime versus linking setup, but this setup works for us and should not affect the existing builds. Fixes pytorch#44470 Pull Request resolved: pytorch#43532 Reviewed By: mrshenli Differential Revision: D24053767 Pulled By: albanD fbshipit-source-id: 1127fefe5104d302a4fc083106d4e9f48e50add8
mruberry
added
the
triaged
|
@malfet, are you the correct person to review this? |
|
@mruberry, I am, although this is just a cherry-pick from master. |
|
Just double-checking all is well here? It seems most branches in the 1.7.0 issue tracker mentioned after this one have been merged? |
|
@adampauls Looking at the code, it seems that this change disabled this codepath on Windows for both default static library build, which can lead to crashes during application shutdown is library is linked to an executable. |
|
I think that's already accomplished by Lines 135 to 137 in b1d24dd |
|
Friendly ping, I noticed this missed the RC2 train. |
|
@malfet friendly ping, seems this missed RC3 too. |
|
@malfet should I assume this won't make it in for 1.7 then? |
Cherry-pick of #43532 onto release/1.7.
Summary:
We are trying to build libtorch statically (BUILD_SHARED_LIBS=OFF) then link it into a DLL. Our setup hits the infinite loop mentioned here because we build with
BUILD_SHARED_LIBS=OFFbut still link it all into a DLL at the end of the day.This PR fixes the issue by changing the condition to guard on which windows runtime the build links against using the
CAFFE2_USE_MSVC_STATIC_RUNTIMEflag.CAFFE2_USE_MSVC_STATIC_RUNTIMEdefaults to ON whenBUILD_SHARED_LIBS=OFF, so backwards compatibility is maintained.I'm not entirely confident I understand the subtleties of the windows runtime versus linking setup, but this setup works for us and should not affect the existing builds.
Fixes #44470
Pull Request resolved: #43532
Reviewed By: mrshenli
Differential Revision: D24053767
Pulled By: albanD
fbshipit-source-id: 1127fefe5104d302a4fc083106d4e9f48e50add8
Fixes #{issue number}