Windows C extension compilation issues

[hmaarrfk]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

conda-forge/sam-2-feedstock#16

Shows some errors in inspecting windows linked libraries.

I feel like it is similar to the challenges we faced moving the shared libraries around for Linux.

Installed packages

PyTorch CUDA 12.6 2.5.1

Environment info

Windows azure CI with CUDA build environment.

[isuruf]

The issue is that libtorch on windows puts the DLLs in Lib/site-packages instead of Library/bin.

[hmaarrfk]

Right. I just wanted to share this observation before too many downstream packages get rebuilt.

[hmaarrfk]

What is the correct course of action on windows? I feel like the symlink trick we used for Linux isn’t appropriate for windows right?

pytorch-cpu-feedstock/recipe/build.sh

Line 226 in 39b84c3

cp ${SP_DIR}/torch/lib/libtorch_python${SHLIB_EXT} ${PREFIX}/lib

[mgorny]

I'm also seeing TorchAudio fail to build because it can't find CMake files:

conda-forge/torchaudio-feedstock#14

I suppose I could try working it around by overriding CMake paths.

[hmaarrfk]

Those azure links are flaky. Can you also link to the PR?

[mgorny]

Updated. That said, passing Torch_ROOT worked.

[isuruf]

What is the correct course of action on windows? I feel like the symlink trick we used for Linux isn’t appropriate for windows right?

The symlinks are not needed for windows. Just moving the .dlls should make it work. We might need to fix some places where downstreams look for .lib files.

[h-vetinari]

Just moving the .dlls should make it work. We might need to fix some places where downstreams look for .lib files.

Do you mean moving the .lib files to LIBRARY_LIB as well? Or would you like to leave them in %SP_DIR%\..., while pointing to the respective DLL in %LIBRARY_BIN%?