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
ctypes cfield.c defines duplicate ffi_type_* symbols #90056
Comments
ctypes's cfield.c redefines a couple of symbols like ffi_type_void and others. The symbols are exported by ffi.h and libffi for more than 12 years: https://github.com/libffi/libffi/blame/e1539266e6c6dde3c99832323586f33f977d1dc0/include/ffi.h.in#L184 I think we can safely remove the symbols from the file. The idea is inspired by pyodide patch https://github.com/pyodide/pyodide/blob/main/cpython/patches/remove-duplicate-symbols-from-cfield.c.patch |
Windows tests are failing without ffi_type_ symbols: cfield.obj : error LNK2001: unresolved external symbol _ffi_type_double [D:\a\cpython\cpython\PCbuild\_ctypes.vcxproj] |
This is because we use libffi as a DLL and you can't statically reference dynamically loaded addresses on Windows. You could change that format table to be initialised on first use, or resolve the FFI type lazily. Or change ctypes to statically link libffi (including updating our FFI build, which IIRC is the one that requires Cygwin, to generate static libraries instead of dynamic) - we can't backport this change, either, because it affects the layout on disk. |
I have applied the patch to main branch (3.11). The workaround for Windows turned out to be more elaborate than initially anticipated. I'm not going to backport the fix to 3.10 and 3.9. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: