MacOS x86 conda, Removing conda-forge dependency and mkl constraint causes torchaudio conda builds to include new mkl dependency

[atalman]

🐛 Describe the bug

1. Removing conda-forge dependency caused python 3.10 failure in conda-py3.10-cpu MacOS build failure: https://github.com/pytorch/audio/actions/runs/4437499067/jobs/7787275986
   That was caused by old mkl version being pinned: CONDA_EXTRA_BUILD_CONSTRAINT=- mkl<=2021.2.0

2. Removing MKL constraint: Remove mkl in for MacOS builds test-infra#3896
   creates a side effect of new dependencies being added in torchaudio:

@rpath/libmkl_intel_ilp64.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libmkl_core.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libmkl_intel_thread.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)

3. Trying to mitigate this issue by compiling torchaudio with openblas blas=*=openblas fails since torch is build with mkl:

https://github.com/pytorch/test-infra/actions/runs/4473835951/jobs/7861672859

Package blas conflicts for:
blas=[build=openblas]
pytorch==2.1.0.dev20230320 -> blas=[build=mkl]
numpy[version='>=1.11'] -> blas[version='*|*|1.0|1.0',build='mkl|mkl|openblas|openblas']

Related issues:
#2784
pytorch/pytorch#62424

cc @ezyang @malfet @seemethere @mthrok

Versions

nightly

[atalman]

We want to have only the following dependencies for libtorchaudio:

otool -L libtorchaudio.so 
libtorchaudio.so:
	@rpath/libtorchaudio.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtorch.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtorch_cpu.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libc10.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)

mkl is not required dependency, however now we have following:

@rpath/libtorchaudio.so (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtorch.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libtorch_cpu.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libc10.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmkl_intel_ilp64.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmkl_core.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libmkl_intel_thread.1.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0)
	@rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)

[mthrok]

My observations

• The link command like L1355 does append -lmkl_intel_ilp64 -lmkl_core -lmkl_intel_thread
• cmake does find and sets MKL at L348-353

  -- MKL_ARCH: None, set to ` intel64` by default
  -- MKL_ROOT $PREFIX
  -- MKL_LINK: None, set to ` dynamic` by default
  -- MKL_INTERFACE_FULL: None, set to ` intel_ilp64` by default
  -- MKL_THREADING: None, set to ` intel_thread` by default
  -- MKL_MPI: None, set to ` mpich` by default
  

• My local build, which depends on nightly distribution is not linked against MKL. otool shows what we expect

  otool -L torchaudio/lib/libtorchaudio.so
  torchaudio/lib/libtorchaudio.so:
      @rpath/libtorchaudio.so (compatibility version 0.0.0, current version 0.0.0)
      @rpath/libtorch_cpu.dylib (compatibility version 0.0.0, current version 0.0.0)
      @rpath/libc10.dylib (compatibility version 0.0.0, current version 0.0.0)
      @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
      /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
  

This suggests that there is something that triggers MKL linking when building the package on CI/Conda-build.

Since MKL should be configured in PyTorch's CMake, looking at the CMake files distributed by PyTorch, I see something like the followings however this does not give me any further clue.

$ grep MKL -B2 -A2 -i -r $(python -c 'import torch;print(torch.utils.cmake_prefix_path)')
...
torch/share/cmake/Torch/TorchConfig.cmake-  if(OFF)
torch/share/cmake/Torch/TorchConfig.cmake:    append_torchlib_if_found(dnnl mkldnn)
torch/share/cmake/Torch/TorchConfig.cmake-  endif()
...
torch/share/cmake/Caffe2/Caffe2Config.cmake: include("${CMAKE_CURRENT_LIST_DIR}/public/mkl.cmake")
...

I think the next step is to find where the MKL configuration is happening in PyTorch cmake files.

-- MKL_ARCH: None, set to ` intel64` by default
-- MKL_ROOT $PREFIX
-- MKL_LINK: None, set to ` dynamic` by default
-- MKL_INTERFACE_FULL: None, set to ` intel_ilp64` by default
-- MKL_THREADING: None, set to ` intel_thread` by default
-- MKL_MPI: None, set to ` mpich` by default

[atalman]

@mthrok Here is related PR that deals with MKL issue in core: pytorch/pytorch#89359

[mthrok]

Fixed by #3307