[BUG] migration to cython3.0.5: redefinition of '__Pyx_Enum_<enum_name>_to_py

[EdwardSro]

Describe the bug

I'm having an issue with migrating PyVerbs package, part of the upstream rdma-core, to cython3.
We've been working for a few years with Cython 0.2X.YY versions without the below issues.
And I didn't find a solved issue for this or any relevant notes in the migration document.

<path-to-rdma-core>/rdma-core/build-fc39/pyverbs/srq.c:5528:18: error: redefinition of '__Pyx_Enum_ibv_ops_wr_opcode_to_py'
5528 | static PyObject *__Pyx_Enum_ibv_ops_wr_opcode_to_py(enum ibv_ops_wr_opcode __pyx_v_c_val) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<path-to-rdma-core>/rdma-core/build-fc39/pyverbs/srq.c:4511:18: note: previous definition of '__Pyx_Enum_ibv_ops_wr_opcode_to_py' with type 'PyObject *(enum ibv_ops_wr_opcode)' {aka 'struct _object *(enum ibv_ops_wr_opcode)'}
4511 | static PyObject *__Pyx_Enum_ibv_ops_wr_opcode_to_py(enum ibv_ops_wr_opcode __pyx_v_c_val) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[420/575] Building C object pyverbs/CMakeFiles/cq.cpython-312-x86_64-linux-gnu.dir/cq.c.o

Code to reproduce the behaviour:

Go to rdma-core project and checkout this PR branch:Update to fc39
Then, to build, and reproduce, you can do:

buildlib/cbuild build-images fc39
buildlib/cbuild make fc39

Expected behaviour

I expect the compilation to pass as it's been passing on any Cython 0.29.XY versions.
The cythonization process creates a duplicate enum definition in the C files due to the "inlucde <pxd_file_name>.pxd" lines.

OS

Linux

Python version

3.10.8

Cython version

3.0.5 (actually from any cython3 version)

Additional context

No response

[da-woods]

That's almost certainly a bug rather than something that should be in the migration notes.

[da-woods]

My suspicion (based on a quick look through the code) is that this is to do with duplicating enums via both include and cimport. That isn't based on any actual debugging so could well be wrong.

If that's the case it may be difficult for Cython to deal with - it'd be better to raise an error earlier rather than generating invalid C code though.

[EdwardSro]

My suspicion (based on a quick look through the code) is that this is to do with duplicating enums via both include and cimport. That isn't based on any actual debugging so could well be wrong.

@da-woods Firstly, thanks for your quick response!
The "include" you see in some of the pxd files (such as "include 'libibverbs_enums.pxd'" in pyverbs/libibverbs.pxd file) is made to allow the required enums to be accessible by relevant structs or function definitions.
What happens, from what I understand, is when other pyx files cimport from both libibverbs.pxd and libibverbs_enums.pxd, the enum defs get duplicated by the cythonization process.

But this behavior was protected and worked for years, up until cython3.
So I consider it as a bug.

[EdwardSro]

BTW, I tried to prevent that by removing the direct enums cimports and cimport from teh files that already includes them.
In the example above, instead of doing:

cimport pyverbs.libibverbs_enums as e
cimport pyverbs.libibverbs as v
#then: v.<some_struct>; e.<some_enum>

I did:

cimport pyverbs.libibverbs as v
#then: "indirectly" accessing by: v.<some_struct>; v.<some_enum>

The compilation succeeds, but I get a lot of UserWarnings in runtime, such as:

$ python3 tests/run_tests.py -v --help
<frozen importlib._bootstrap>:241: UserWarning: enum class rdma_port_space not importable from pyverbs.librdmacm. You are probably using a cpdef enum declared in a .pxd file that does not have a .py  or .pyx file.
<frozen importlib._bootstrap>:241: UserWarning: enum class ibv_send_flags not importable from pyverbs.libibverbs. You are probably using a cpdef enum declared in a .pxd file that does not have a .py  or .pyx file.
<frozen importlib._bootstrap>:241: UserWarning: enum class ibv_wr_opcode not importable from pyverbs.libibverbs. You are probably using a cpdef enum declared in a .pxd file that does not have a .py  or .pyx file.
<frozen importlib._bootstrap>:241: UserWarning: enum class ibv_ops_wr_opcode not importable from pyverbs.libibverbs. You are probably using a cpdef enum declared in a .pxd file that does not have a .py  or .pyx file.
<...........>

While every enum.pxd file has a corresponding enum.pyx file (usually as a symlink)

[EdwardSro]

@da-woods Could you please take a look at this issue?
It's blocking Linux rdma-core subsystem from being built on any OS with cython3+

[scoder]

The "include" you see in some of the pxd files (such as "include 'libibverbs_enums.pxd'" in pyverbs/libibverbs.pxd file) is made to allow the required enums to be accessible by relevant structs or function definitions.

A cimport should be enough for that. An include that duplictes the enum declarations seems incorrect and is also probably not what you want. I suggest removing/replacing the include statements.

[da-woods]

Re-opening this because it probably wasn't fixed by #5887. Don't think I'll be able to track down the issue though

[da-woods]

Don't think I'll be able to track down the issue though

Actually, possibly might - I missed the bit about build_images and just looked at the readme. No promises though

[EdwardSro]

Actually, possibly might - I missed the bit about build_images and just looked at the readme. No promises though

It's quite easy to reproduce it, no need to install dependencies manually, rdma-core provides a tool that compiles it on a containerized environment . After checking out to this branch you can run:
buildlib/cbuild build-images fc39; buildlib/cbuild make fc39
The second command (compilation of the project) would fail and reproduce the issue.

[EdwardSro]

A cimport should be enough for that. An include that duplictes the enum declarations seems incorrect and is also probably not what you want. I suggest removing/replacing the include statements.

I already tried that but had enums exposure issues in python runtime.
Even if I find a workaround or solution with cimports only, this behavioral change breaks backward compatibility for a Cython 0.2X code... and most probably was not done on purpose/has any motivational reasoning.

[da-woods]

Reopening because this exact issue will be fixed by #5905 - e6490a6 was related but not quite the same

[Pro-pra]

update cython3.0.8 not help build rdma-core :-(

[da-woods]

Closed in 0185350