gh-125206: Correct detection of complex numbers support in libffi

[skirpichev]

• Issue: CTypes test failed, complex double problem #125206

[skirpichev]

!buildbot SPARCv9 Oracle Solaris 11.4

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit 66c1cf7 🤖

The command will test the builders whose names match following regular expression: SPARCv9 Oracle Solaris 11.4

The builders matched are:

• SPARCv9 Oracle Solaris 11.4 PR

[skirpichev]

!buildbot PPC64LE CentOS9 LTO + PGO

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit 66c1cf7 🤖

The command will test the builders whose names match following regular expression: PPC64LE CentOS9 LTO \+ PGO

The builders matched are:

• PPC64LE CentOS9 LTO + PGO PR

[skirpichev]

PPC64LE build works as expected (no support)

[skirpichev]

!buildbot SPARCv9 Oracle Solaris 11.4

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit fc4ebff 🤖

The command will test the builders whose names match following regular expression: SPARCv9 Oracle Solaris 11.4

The builders matched are:

• SPARCv9 Oracle Solaris 11.4 PR

[skirpichev]

Hmm, now on SPARCv9 - libffi support was detected. Test failures seems unrelated and build was successful. (C.f. https://buildbot.python.org/all/#/builders/1262/builds/13 and https://buildbot.python.org/#/builders/1262/builds/21)

[vstinner]

@efimov-mikhail: Can you test the fix on Debian 10?

[skirpichev]

I don't expect something new, as on his local system patch was working: #125322 (comment) (test code was unchanged)

[efimov-mikhail]

@efimov-mikhail: Can you test the fix on Debian 10?

Yes, I can. It looks like the correct fix, but it's better to test again.

[efimov-mikhail]

This fix works fine on Debian 10.

[erlend-aasland]

LGTM (if the Sparc failure is unrelated).

[vstinner]

Merged, thanks.

LGTM (if the Sparc failure is unrelated).

There are tons of unrelated errors/test failures on Solaris.

[skirpichev]

On SPARCv9 only configure test was checked. It reports "yes" (supported). But it seems that ctypes tests weren't run. Sadly that configure script doesn't report library versions (even if this is available e.g. with pkg-config --modversion <lib>.

[erlend-aasland]

On SPARCv9 only configure test was checked. It reports "yes" (supported). But it seems that ctypes tests weren't run. Sadly that configure script doesn't report library versions (even if this is available e.g. with pkg-config --modversion <lib>.

We could fix that if we wanted.

[skirpichev]

We could fix that if we wanted.

If that does make sense, I can open an issue. But I admit, that I don't know how to solve this in general: maybe every snowflake^Wlibrary will require a special treatment.

BTW, version information is unavailable in the config.log (even for versioned checks like for libmpdec).

[erlend-aasland]

IIRC (from the top of my head), the pkg-config macro will print version information if you specify version bounds (see the sqlite3 third-party detection code in configure.ac). My gut feeling for implementing such a thing would be to create a wrapper for PKG_CHECK_MODULES and ensure that we print version info in the action-if-found block. I'm not sure if it is worth it, but it would be convenient for debugging third-party dependency detection.

[skirpichev]

the pkg-config macro will print version information if you specify version bounds (see the sqlite3 third-party detection code in configure.ac).

Quick test for mpdec (which uses same PKG_CHECK_MODULES macro for system libmpdec, just as for sqlite3) shows, that it's not true:

$ ./configure 2>&1|grep mpdec
checking for --with-system-libmpdec... yes
checking for libmpdec >= 2.5.0... yes