Add abi3audit check for stable ABI violations to CI

[nicholasjng]

Only applies to CPython>=3.12.

[nicholasjng]

Nice, the wheel ABI tag comes out correct, and no ABI violations are found (although it would probably be hard to produce one with just the given example?).

[wjakob]

When compiling stable ABI wheels, are you passing Py_LIMITED_API? (Without that flag, nanobind will index into various version-specific data structures, but such a violation may not necessarily be found by an ABI audit that checks for the presence of disallowed symbols)

[nicholasjng]

I compile the nanobind .so with -DPy_LIMITED_API=0x030?0000, given via the selected ABI version here:

nanobind-bazel/helpers.bzl

Lines 17 to 22 in 97e3db2

	def pyversionhex():
	return select({
	"@nanobind_bazel//:cp312": ["Py_LIMITED_API=0x030C0000"],
	"@nanobind_bazel//:cp313": ["Py_LIMITED_API=0x030D0000"],
	"@nanobind_bazel//:pyunlimitedapi": [],
	})

I pass that as a define to @nanobind//:nanobind here:

nanobind-bazel/nanobind.BUILD

Line 33 in 97e3db2

defines = pyversionhex(),

which by default propagates to consuming rules. I do not, however, define the Py_LIMITED_API macro in the setuptools.Extension, for example in your nanobind_example, but that should not be an issue, since setuptools' C++ toolchain is not used by Bazel.

Does that seem correct?

[wjakob]

The first part sounds good, the second part I don't understand. In the nanobind_example, it's cmake that produces the commands that will eventually compile and link code, hence it is the component responsible for setting these flags. I don't think setuptools does anything interesting here besides, perhaps, choosing the name of the final wheel.

[nicholasjng]

Sorry, I meant on the bazel branch which you allowed me to push, that contains a setuptools+Bazel approach (though it's very rough).

[wjakob]

got it, thanks!