ctypes.util.find_library is incompatible with `ld` being `mold`

[encukou]

When ld is mold:

$ ld --version
mold 2.40.4 (compatible with GNU ld)

then the soft-deprecated ctypes.util.find_library fails to find libraries.
With GNU ld, find_library(c) does something like:

$ ld -t -o /dev/null -lc
/usr/lib64/libc.so
/lib64/libc.so.6
/usr/lib64/libc_nonshared.a
/lib64/ld-linux-x86-64.so.2
/usr/lib64/libc_nonshared.a
/lib64/ld-linux-x86-64.so.2
/usr/bin/ld.bfd: warning: cannot find entry symbol _start; not setting start address

But, mold does not support -t, and even the equivalent --trace doesn't work the same:

$ mold --trace -o /dev/null -lc
mold: fatal: -m option is missing

This matches find_library's documented behaviour:

If no library can be found, return None.
[...]
Soft deprecated since version 3.15: This function is kept for use in cases where it works, but not expected to be updated for additional platforms and configurations.

so we should skip the test.

Note that switching to --trace ... might break other lds. Fixing one unsupported configuration is not worth possibly breaking other unknown ones.

Linked PRs

• gh-157983: Skip test for ctypes.util.find_library when ld is mold #157984
• [3.15] gh-157983: Skip test for ctypes.util.find_library when ld is mold (GH-157984) #158008
• [3.14] gh-157983: Skip test for ctypes.util.find_library when ld is mold (GH-157984) #158009

[encukou]

In 3.13-3.14, find_library is not officially soft-deprecated, but the docs have been weasel-worded since before Python 3:

Try to find a library [...]. If no library can be found, returns None.

[furkanonder]

I hit this too, on the riscv64 worker I run (VisionFive 2, Debian trixie): https://buildbot.python.org/all/#/builders/2189
ld was mold there because I had put /usr/libexec/mold on the worker's PATH.