Skip to content
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

Add free-threading support #39

Merged
merged 4 commits into from
Oct 14, 2024
Merged

Add free-threading support #39

merged 4 commits into from
Oct 14, 2024

Conversation

nicholasjng
Copy link
Owner

Contains a flag for the NB_FREE_THREADED define, which goes into the compilation of libnanobind.

Closes #37.

Contains a flag for setting `NB_FREE_THREADED`, and config settings for
each.
Via `pre-commit autoupdate`.
@nicholasjng
Copy link
Owner Author

@wjakob I briefly skimmed your PR again and found some new logic in the CMakeLists.txt regarding SO files - do I need to put -ft as an extension for free-threaded builds, or is that only internal to libnanobind?

@nicholasjng
Copy link
Owner Author

Hm, looks like nanobind module initialization in C++ fails for Python <3.12.

I'm currently on the train (with horrendous wifi), will investigate later today.

@nicholasjng
Copy link
Owner Author

nicholasjng commented Oct 7, 2024

It was the same regression for extensions without files in setuptools 73 that wrecked Google Benchmark earlier. Pinning to setuptools<73 in nanobind example's pyproject.toml solves the problem.

I'm currently unable to verify if free-threading works here, since rules_python has not yet merged any 3.13 toolchain support, much less included them in a release. When that happens, I can add 3.13 to the nanobind example test matrix.

With that in mind, I hope to release nanobind_bazel v2.2.0 this week - since we're now even again with nanobind itself, I'm thinking of aligning it again with nanobind's SemVer, and releasing .bzl.N tags for development progress, effectively treating them as .devN tags in nanobind. The reason, of course, being that this decoupled SemVer behavior is just too unexpected and confusing for users.

EDIT: Side note, --free_threading with an older interpreter raises a good error:

ERROR: /Users/nicholasjunge/Workspaces/c++/nanobind_example/src/BUILD:14:19: Compiling src/nanobind_example_ext.cpp failed: (Exit 1): cc_wrapper.sh failed: error executing CppCompile command (from target //src:nanobind_example_ext.so) external/bazel_tools~cc_configure_extension~local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object ... (remaining 67 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from src/nanobind_example_ext.cpp:1:
In file included from external/nanobind_bazel~~internal_configure_extension~nanobind/include/nanobind/nanobind.h:40:
external/nanobind_bazel~~internal_configure_extension~nanobind/include/nanobind/nb_defs.h:151:6: error: "Free-threaded extensions require a free-threaded version of Python"
#    error "Free-threaded extensions require a free-threaded version of Python"

@nicholasjng nicholasjng merged commit 13b6b8e into master Oct 14, 2024
16 checks passed
@nicholasjng nicholasjng deleted the free-threading-support branch October 14, 2024 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support free-threaded (nogil) Python builds
1 participant