Repository navigation
CTypes test failed, complex double problem #125206
Description
Activity
cc @skirpichev
Reacted by Mikhail EfimovLooks to be libffi issue.
Here is what I see.
- other tests don't fail (i.e. round-trip to/from c_double_complex)
- @efimov-mikhail, you are on Debian 10 (buster), that has libffi v3.2.1; are you using this version?
- if so, can you try to link CPython with never libffi (which, probably is available in backports)? Any v3.3+ should be fine.
It seems, that real support for complex types was added on x86_65 in v3.3-rc0. Similar failure was on Sparc during testing my pr, see this. I hoped, it was workarounded.
Edit: yes, they just did it - https://github.com/libffi/libffi/blob/v3.2.1/src/x86/ffitarget.h. Unfortunately, there is no way to detect libffi support for complex types at compilation time. There is even no version define.
Reacted by Mikhail Efimov- @efimov-mikhail, you are on Debian 10 (buster), that has libffi v3.2.1; are you using this version?
- if so, can you try to link CPython with never libffi (which, probably is available in backports)? Any v3.3+ should be fine.
The answer is "yes" on both questions.
All work fine with libffi-3.3-rc1.Edit: yes, they just did it - https://github.com/libffi/libffi/blob/v3.2.1/src/x86/ffitarget.h. Unfortunately, there is no way to detect libffi support for complex types at compilation time. There is even no version define.
What do you think about adding some workaround to configure.ac?
It can be in form of something like this:
Write little code snippet which uses ffi_type_complex_double, calculate clog(1000.0) and exit with error code if creal(clog(1000.0)) less than 5.0.
Build this snippet with linking to libffi, test the result of binary execution.
And properly define FFI_ACTUALLY_HAS_COMPLEX_TYPE value.What do you think about adding some workaround to configure.ac?
It's a bug. There should be a proper fix to exclude bad library versions. I'm thinking on just
diff --git a/configure.ac b/configure.ac index 1864e94ace..559b513062 100644 --- a/configure.ac +++ b/configure.ac @@ -4043,7 +4043,7 @@ AS_VAR_IF([ac_sys_system], [Darwin], [ ]) ]) AS_VAR_IF([have_libffi], [missing], [ - PKG_CHECK_MODULES([LIBFFI], [libffi], [have_libffi=yes], [ + PKG_CHECK_MODULES([LIBFFI], [libffi >= 3.3], [have_libffi=yes], [ WITH_SAVE_ENV([ CPPFLAGS="$CPPFLAGS $LIBFFI_CFLAGS" LDFLAGS="$LDFLAGS $LIBFFI_LIBS"
v3.3 was released in Nov 2019. Not sure if this is acceptable, however. @Eclips4 ?
Write little code snippet which uses ffi_type_complex_double, calculate clog(1000.0) and exit with error code if creal(clog(1000.0)) less than 5.0.
Or some variant along this road.
I would rather create a test function, that get expected complex input (say
1.25+0.5j) and compares that with local values and then reports result. We should call this with ffi_call() and report result to the configure script.Let me know if you would like to work on this.
It's a bug. There should be a proper fix to exclude bad library versions. I'm thinking on just <ignore libffi with versions less than 3.3>
IMO, there is no need to fully ignore libffi linking with old versions since workaround is simple and issue only relates to complex double/float/long double types.
Moreover, supporting of complex numbers without C11 complex types is okay, and making harder assumptions on system libraries just for those types seems to be redundant.expected complex input (say 1.25+0.5j)
Agree, checking
clog(1.25+0.5j) == (0.2973535538733464+0.3805063771123649j)seems to be optimal.
Let me know if you would like to work on this.
Yes, I would like to create a PR.
Agree, checking clog(1.25+0.5j) == (0.2973535538733464+0.3805063771123649j) seems to be optimal.
Not at all. What I would suggest instead is something like
int foo (double complex z) { const double complex expected = CMPLX(1.25, -0.5); return z == expected; }
Then ffi_call this with expected argument. All this is actually about passing arguments correctly.
You can try to use instead libm complex functions, but you shouldn't compare computed values exactly.
Yes, I would like to create a PR.
Ok. Feel free to ping me for review.
Reacted by Mikhail EfimovFixed
7 remaining items
- added a commit that references this issue
on Oct 30, 2024 - added a commit that references this issue
on Apr 24, 2025
Bug report
Bug description:
Python binary has been built in the standard way:
But test_ctypes fails:
System:
GCC:
I've tried to fix it by myself but the result has not been achieved in a reasonable amount of time.
There is a simple test I've provided:
So, it's not a problem in my libc version.
Moreover, this problem can be reproduced with standard libm.so (/lib/x86_64-linux-gnu/libm-2.28.so):
IMHO, some problem lies in using ctypes.c_double_complex as an argument and return value types.
FYI, with double argtype and restype clog works like classical double log:
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs