Building against Python3.11 still brings in undefined symbol PyErr_GetRaisedException

[stellarpower]

Hi,

Afraid I can't get full details just the now, but I am using xmake and from the verbose output it seems specifying using Python3.11 is pulling in the dependent package and compiling and linking correctly against this version. However when I import the package in the interpreter, I have undefined symbols from PyErr_GetRaisedException, so it seems somehow nanobind is still linking against this even though it was only introduced in Python3.12.

Do you know if there's a probable cause for this, a preprocessor macro perhaps that needs to be defined? It's quite possible that the xmake package is not complete but wondering if maybe support has been dropped in version 2.8.0 and this is to be expected or there is something to be aware of before investigating further

Thanks!

[wjakob]

The xmake build system is not part of this project, you'll have to check with whoever implemented it.

[stellarpower]

It's calling cmake behind the scenes and I can send the compile commands, but, what I'm asking is does anything else need to happen to specify the python version or should pointing it to the headers be sufficient? The recipe is pretty straightforward. If the python version macro that's used to conditionally compile in that call is coming from the heaaders then this shouldn't be happening; if more needs to be specified to CMake, then I can add that in. Is 3.11 still supported presumably?

[hpkfft]

Yes, Python 3.11 is supported by nanobind.
Did you specify the Python version in your CMake find_package() command and specify EXACT?
See: https://cmake.org/cmake/help/latest/command/find_package.html
Also, you can try setting Python_ROOT_DIR
See also: https://cmake.org/cmake/help/latest/module/FindPython.html

[stellarpower]

To clarify, do you mean a find_package for python itself or for nanobind? Python is being brought in natively using xmake's package manager.

[hpkfft]

I mean find_package for Python itself.
If Python is being brought in natively using xmake's package manager, then you'll have to check with them.

[stellarpower]

Okay thanks. I've linked what's happening above and it's pretty simple, so if there's nothing else I need to do and I can't point nanobind to it explicitly through its own cmake arguments then I will try patching nanobind's CMakeLists to specify an exact version and see if that then stops it from locating a system python.

[stellarpower]

Could I just confirm my mental model, as I've not really used CMake in a couple of years now?

If I want to pin python to a specific version, is the intended flow that for my application, I would first find the python version/path/whatever I want through my own CMakelists, by providing the papropriate arguments or calls within CMake first-class, and then after that, by finding Nanobind, nanobind's search will then use the Python CMake cached from before? So rather than jamming a load of arguments into Nanobind when I bring the package in, I have already told CMake where to find the desired python myself, and thus nanobind's search is trivial?

Thanks

[hpkfft]

I'm not a CMake expert. With that said, in my opinion, your mental model is correct.
Your own CMakeLists.txt can do:

find_package(Python 3.11 EXACT
                         REQUIRED COMPONENTS Interpreter Development.Module
                         OPTIONAL_COMPONENTS Development.SABIModule)

Then nanobind won't run find_package in Line 148 because of the test in Line 139.