Windows: No LTO#22
Merged
Merged
Conversation
Trips up MSVC in linking
Member
Author
|
Ok, we can ignore 32bit Windows for now. |
ax3l
added a commit
to AMReX-Codes/pyamrex
that referenced
this pull request
May 5, 2026
The existing `space1d`/`space2d`/`space3d` package initializers each carried the same Windows DLL setup code before importing their pybind extension. That logic only added the current package directory plus entries already present on `PATH` via `os.add_dll_directory()`. In practice this was fragile for wheel installs because the extension import could still fail if dependent DLLs were bundled in package-local locations that were not already on `PATH`. Example: for ImpactX wheels we just build **one** ImpactX wheel that vendors the AMReX and ImpactX libs and both the pyAMReX and pyImpactX sources: BLAST-ImpactX/impactx-wheels#22 (We do not yet publish AMReX wheels.) Centralize the DLL search setup in `amrex._dll` and call it from each `spaceNd` package before importing `amrex_*d_pybind`. The new helper prefers package-local locations first: the current `spaceNd` directory, `spaceNd/.libs`, the parent amrex package directory, and `amrex/.libs`. It then falls back to `PATH` for source and developer installs. Keep the `os.add_dll_directory()` handles alive for the lifetime of the process and deduplicate discovered paths. This keeps the Windows import workaround in one place and makes it compatible with vendored wheel layouts as well as traditional shared- library installs.
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.
Trips up MSVC in linking.
Fix #1
Close #2
Details
PR 21 on March 25, 2026 and PR 20 on February 10, 2026 both still hit the same Windows failure: the pyImpactX module is compiled with /GL and linked with /LTCG, then MSVC dies during LTCG on src/
python/wakeconvolution.cpp with C1001, followed by LNK1000. The 32-bit Windows job does the same thing. So this is not a random linker-only failure; it is link-time codegen walking back into that
translation unit.
The reason is in upstream ImpactX, not in the wheel helper scripts. In impactx CMakeLists.txt (https://github.com/BLAST-ImpactX/impactx/blob/26.03/CMakeLists.txt), ImpactX_IPO defaults OFF, but Imp
actX_PYTHON_IPO defaults ON unless CMAKE_INTERPROCEDURAL_OPTIMIZATION is explicitly defined. When ImpactX_PYTHON_IPO is on, pyImpactX links pybind11::lto. In setup.py
(https://github.com/BLAST-ImpactX/impactx/blob/26.03/setup.py), the wheel build only forwards CMAKE_INTERPROCEDURAL_OPTIMIZATION from the environment, and the wheel workflow was not setting it. That
is why the build summary can still print IPO/LTO: OFF while the actual Windows commands still contain /GL and /LTCG.
PR 2 changed the toolset to ClangCl, but it did not disable this IPO/LTO path. So it was working around the compiler choice, not the flag combination that actually triggers the failing LTCG pass. I
could not confirm the exact PR 2 failure mode because GitHub has already expired that Actions log and now returns HTTP 410 for it. That part is inference.
I patched the workflow locally at .github/workflows/build.yml:160 to add CMAKE_INTERPROCEDURAL_OPTIMIZATION='OFF' to CIBW_ENVIRONMENT_WINDOWS. That is the cleanest knob here because upstream
setup.py already forwards it, and upstream CMake already uses it to suppress Python IPO/LTO.