Repository navigation
macOS: find libomp in the environment being built into (backport #58) - #59
Merged
Merged
Conversation
The Darwin block probes $CONDA_PREFIX/include/omp.h and falls back to Homebrew.
That misses the case where the activated environment is not the one being built
into: conda-build and rattler-build activate their own base installation and
install into $PREFIX, so a recipe that puts llvm-openmp in the host environment
still fails with
Error: no OpenMP runtime found on this macOS host.
Looked in $CONDA_PREFIX/include and /opt/homebrew/opt/libomp/include.
on a builder with no Homebrew libomp -- while the header sits unexamined in
$PREFIX. This is what the conda-forge osx_64 build hits.
Consult sys.prefix, then sys.base_prefix, after CONDA_PREFIX and before
Homebrew. sys.prefix is the prefix of the interpreter running setup.py, which
under both build backends is the environment the extension is built for; it is
also the convention _mpi_prefix_from_env_prefix() already uses, which is why MPI
detection succeeded in the same build where OpenMP failed.
CONDA_PREFIX stays first, so an ordinary activated environment behaves exactly
as before. The new candidates can only be reached where the code previously
fell through to Homebrew, so no build that passes today changes behavior.
This serves the intent of the original change rather than reversing it: build
against the libomp that will be LOADED at import time, resolved through the
interpreter's rpath. Linking the base installation's copy while installing into
$PREFIX is how a process ends up with two LLVM OpenMP runtimes, the abort
described in the README and tracked as #27.
The error message listed $CONDA_PREFIX literally, which no longer describes the
set of prefixes searched, so report the paths actually tried, deduplicated.
Assisted-by: Claude Opus 5
(cherry picked from commit b49c22b)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On macOS the build locates
libompby probing$CONDA_PREFIX/include/omp.h, falling back to Homebrew. That misses the case where the activated environment is not the one being built into. conda-build and rattler-build activate their own base installation and install into$PREFIX, so a recipe that providesllvm-openmpstill fails:on a builder with no Homebrew
libomp— while the header sits unexamined in$PREFIX. This is what the conda-forgeosx_64build hits (staged-recipes#35125), whereCONDA_PREFIXis/Users/runner/miniforge3andllvm-openmp 21.1.8is installed in the host environment.The change
Consult
sys.prefix, thensys.base_prefix, afterCONDA_PREFIXand before Homebrew.sys.prefixis the prefix of the interpreter runningsetup.py, which under both build backends is the environment the extension is built for. It is also the convention_mpi_prefix_from_env_prefix()already uses — which is why MPI detection succeeded in the same build where OpenMP failed.CONDA_PREFIXstays first, so an ordinary activated environment behaves exactly as before. The new candidates are reachable only where the code previously fell through to Homebrew, so no build that passes today changes behavior.This serves the intent of the original logic rather than reversing it: build against the
libompthat will be loaded at import time, resolved through the interpreter's rpath. Linking the base installation's copy while installing into$PREFIXis one way to end up with two LLVM OpenMP runtimes in one process — the abort described in the README and tracked as #27.The error message named
$CONDA_PREFIXliterally, which no longer describes the set of prefixes searched, so it now reports the paths actually tried, deduplicated.Verification
The changed branch is
platform.system() == 'Darwin'-only, so it is unreachable on Linux. I exercised the prefix selection directly across six cases: activated environment with the header present (unchanged); activated prefix without it but the build prefix with it (the failure above, now resolved); neither, so the Homebrew fallback still engages; both, confirmingCONDA_PREFIXkeeps precedence;CONDA_PREFIXunset; and onlysys.base_prefixcarrying it.I do not have a macOS host, so the end-to-end check is the conda-forge
osx_64build. I will report back once it has run against this change.This pull request was drafted by Claude Opus 5 under my guidance.
This is an automatic backport of pull request #58 done by [Mergify](https://mergify.com).