-
-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
intel-openmp
should conflict orther impls
#59
Comments
I see this currently in Windows builds, where I build with
since recently. I think the reason is that some Python package I depend on pulls in Example: conda-forge/impactx-feedstock#22 |
Are some packages in Conda-Forge unconditionally using intel_repack-feedstock/recipe/meta.yaml Lines 108 to 122 in 1dd0cb7
Likely scipy: MKL seems to be the default BLAS/LAPACK provider on Windows now, which makes as its direct dependency |
attn @leofang @oleksandr-pavlyk @isuruf @jeffhammond for help. I think two things need to be done (but I do not know how):
|
Like |
Same for cc: @conda-forge/core for vis |
We need to be careful with the mutexes here. They are not like the mpi ones since we allow swapping openmp at runtime due to ABI compat. |
Are there other packages there we allow swap due to ABI compat? Is there process that we can agree following? |
BLAS is done that way. We need input from @isuruf on this since he did most of the design here. |
Additionally, there seems to be a As a temporary work-around, I tried to rewrite all my feedstocks to use
For building, I find OpenMP with CMake's FindOpenMP.cmake. |
@beckermr I am not sure I follow. Regardless of MPI/OpenMP/BLAS, the purpose of the mutexes is the same: Disallowing multiple implementations from being installed to the same conda environment. How the mutex is implemented is an implementation detail that only package maintainers need to know. In the case of MPI, we need to add a string identifier to In the case of BLAS, we need to register the BLAS implementation in the blas-feedstock. In the case of OpenMP, for some reason unclear to me the mutex publishing happens in two feedstocks, ctng-compiler (for gomp) and But in the end, all such packages work with the same concept. Am I missing something? It's worth noting that @h-vetinari also reported this very same issue 2 years ago: conda-forge/_openmp_mutex-feedstock#7 We definitely should fix it. |
Regarding ABI, we have intel-openmp because llvm-openmp does not have the VCOMP symbols in them which leads to pytorch on windows breaking. VCOMP is old and going away in favour of LLVM openmp (even MSVC supports LLVM openmp now). We really should have a pytorch win build in conda-forge and then we can remove intel-openmp. Yes, we can have intel-openmp and llvm-openmp conflict with each other for now. |
@isuruf As mentioned above MKL depends on intel-openmp on Windows. Does intel-openmp need to be replaced with llvm-openmp in MKL too? |
Hi, is there any progress on this, e.g., marking the conflict for `intel-openmp? :) |
Hi, we are also seeing issues for us when developing Windows support for Code Aster due to the clobbering of files when mixing intel-openmp and llvm-openmp when trying to use Would it be possible to switch from intel to llvm openmp for I can try to help with a PR with a little guidance. |
I noticed something similar to the MPI issue with OpenMP since recently: Is it possible that, similar to the recent intel MPI issue, there is another issue that some Python packages started to pull in
intel-openmp
(ormkl
, which requiresintel-openmp
) and do not clearly mark it as alternative to LLVM OpenMP and GNU OpenMP?I think that
intel-openmp
needs to know aboutlibgomp
,llvm-openmp
and thelibomp140.x86_64.dll
that is shipped in Visual Studio/VC4 (?) of Conda-Forge? and conflict properly.https://conda-forge.org/docs/maintainer/knowledge_base.html#openmp
The text was updated successfully, but these errors were encountered: