Open jhale opened 3 weeks ago
We have been getting the same internal compiler error pointing to L42 in nb_func.cpp
since about a day ago.
That's quite mysterious since it doesn't seem to happen in the nanobind CI. Two requests:
Regarding your second point @wjakob
We are using the 2.0.0 tag point release from wjacob/nanobind. We started noticing this error roughly from yesterday. I think it's safe to say that something upstream, either in the MSVC compiler or in the GitHub Windows Server runner image, has changed.
Possibly related issue: https://github.com/actions/runner-images/issues/10004
@wjakob, is it possible for you to trigger a windows-latest
build job for your nanobind Tests job? From looking around a bit over at actions/runner-images, there seems to be a bit of talk going on that something has happened to that image within the last 24 hours. I'm curious if your test build can trigger this internal compiler error.
To throw another datapoint into the mix:
I maintain nanobind-bazel, a Bazel ruleset for Python bindings builds with nanobind, and my CI (which consists of building @wjakob 's nanobind_example across multiple Python versions with the respective installed C++ toolchain on every OS) is still entirely green on 20240603.1.0: https://github.com/nicholasjng/nanobind-bazel/actions/runs/9416682418/job/25940329652#step:1:9
EDIT: I should also say that this is built with nanobind v2.0.0.
Tried on a fork https://github.com/jhale/nanobind, doesn't trigger the issue on either a slightly tweaked v2.0.0 or a current main.
Could you tell us more about your project @miklhh ?
@jhale The issue has been reported and fixed, but they haven't released the patch.
The bug is introduced in MSVC 19.40.xxxxx
Thanks @metab0t - Even though this is not an issue with nanobind itself, I propose we leave this issue open until the fix is rolled out @wjakob?
@jhale I found out that windows-2019
image can be used instead of windows-latest
as a temporary solution to compile nanobind.
Also see https://github.com/pypa/cibuildwheel/issues/1875 for another.
It's quite a strange bug. Since I could build my lib successfully on my win10 laptop with vs2022. But on github action, it just failed. I don't quite understand what's the difference.
Do you have version 17.10 locally? That’s the buggy one that came to GHA a week or two ago. It’s breaking other things too, I’ve seen three unrelated packages broken so far. Older versions are fine.
(edit: sorry, got the first number wrong, fixed it)
I got Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.9.5
locally.
Do you mean the newest 17.10
version?
Yes, got the first number wrong. The buggy one is 17.10. 17.9 is fine.
(If you check the link above, apparently it has been fixed internally, but isn’t in a released version yet, as of 17.10.2)
Problem description
We have recently started building our library Basix on Windows using MSVC 2022 using GitHub Actions. We are using scikit-build-core to orchestrate the CMake build and we build nanobind statically. We use vcpkg to bring in LAPACK and BLAS.
After switching to nanobind 2.0.0 we are consistently triggering an internal compiler error when building nanobind statically. The error points to L42 in
nb_func.cpp
, but that line looks relatively innocent.https://github.com/FEniCS/basix/actions/runs/9404421938/job/25903298628#step:5:763 https://github.com/wjakob/nanobind/blob/master/src/nb_func.cpp#L42
We don't have Windows machines locally so we haven't tried reproducing this locally. Your CI seems to be running green on MSVC 2022. Any ideas?
Reproducible example code
No response