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.