Not explicitly set the manifest filename in Windows

[huydhn]

I'm at a loss to explain why this happens, but not setting the manifest file explicitly in the linker fixes it.

Testing locally

• With /MANIFESTFILE:bin\torch_python.dll.manifest

C:\PROGRA~2\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\link.exe /nologo @CMakeFiles\torch_python.rsp /out:bin\torch_python.dll /implib:lib\torch_python.lib /pdb:bin\torch_python.pdb /dll /version:0.0 /machine:x64 /ignore:4049 /ignore:4217 /ignore:4099 /INCREMENTAL:NO /NODEFAULTLIB:LIBCMT.LIB -WHOLEARCHIVE:C:/actions-runner/_work/pytorch/pytorch/build/lib/onnx.lib /MANIFEST /MANIFESTFILE:bin\torch_python.dll.manifest

LINK : fatal error LNK1000: Internal error during CImplib::EmitImportThunk

• Work fine without the flag

C:\PROGRA~2\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\link.exe /nologo @CMakeFiles\torch_python.rsp /out:bin\torch_python.dll /implib:lib\torch_python.lib /pdb:bin\torch_python.pdb /dll /version:0.0 /machine:x64 /ignore:4049 /ignore:4217 /ignore:4099 /INCREMENTAL:NO /NODEFAULTLIB:LIBCMT.LIB -WHOLEARCHIVE:C:/actions-runner/_work/pytorch/pytorch/build/lib/onnx.lib /MANIFEST 

In both case, the /MANIFEST flag is set, so the manifest file is there. In the latter case, the filename comes by appending .manifest suffix to bin\torch_python.dll. Thus, it's still correctly be bin\torch_python.dll.manifest. Weird.

C:\actions-runner\_work\pytorch\pytorch>ls -la build/bin/torch_*
-rwxr-xr-x 1 runneruser 197121 246796288 Jan 11 04:30 build/bin/torch_cpu.dll
-rw-r--r-- 1 runneruser 197121       381 Jan 11 04:26 build/bin/torch_cpu.dll.manifest
-rwxr-xr-x 1 runneruser 197121      9728 Jan 11 03:55 build/bin/torch_global_deps.dll
-rw-r--r-- 1 runneruser 197121       381 Jan 11 03:55 build/bin/torch_global_deps.dll.manifest
-rwxr-xr-x 1 runneruser 197121  11746816 Jan 11 04:31 build/bin/torch_python.dll
-rw-r--r-- 1 runneruser 197121       381 Jan 11 04:30 build/bin/torch_python.dll.manifest

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/91988

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki or our office hours

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• win-vs2019-cpu-py3 / build workflows failing consistently with linker crash

❌ 1 Failures

As of commit d6821b6:

NEW FAILURES - The following jobs have failed:

• macos-12-py3-arm64 / test (default, 2, 2, macos-m1-12)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[huydhn]

torch_test_cpp_extension does some compilation at testing time https://github.com/pytorch/pytorch/actions/runs/3890569745/jobs/6640722956 and it fails with the following error.

C:\actions-runner\_work\pytorch\pytorch\build\win_tmp\build\torch\include\c10/util/env.h(17): error C4996: 'getenv': This function or variable may be unsafe. Consider using _dupenv_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

This looks unrelated to the linker issue, so I suspect that a recent commit merged while Windows CPU build and tests are disable causes this ( no signal). The fix looks simple enough though.

[huydhn]

I just realize that the same error is also causing failures on periodic https://hud.pytorch.org/commit/pytorch/pytorch/364f526b9cdf9818a7647b5e637efdee825d61a1

[Blackhex]

JFYI, getenv_s should be used instead https://en.cppreference.com/w/c/program/getenv

[huydhn]

Noted, I'll fix this properly in another PR and will merge this once Windows CPU build and test pass.

[Blackhex]

Alternatively including <cstdlib> together with the std:: namespace clasifier might resolve the issue as https://stackoverflow.com/a/631696/685292 or other sources mentions, though I haven't tried it.

[huydhn]

@pytorchbot merge -f 'Windows CPU build and test jobs have passed. MacOS failure is unrelated'

[pytorchmergebot]

Merge started

Your change will be merged immediately since you used the force (-f) flag, bypassing any CI checks (ETA: 1-5 minutes).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging

Check the merge workflow status
here