Created attachment 1384793 [details]
Currently on rawhide a strict symbol check is enforced  meaning that undefined references will make the build fail as shown at the build log.
This can be disabled by utilizing the %undefine _strict_symbol_defs_build macro or by passing the `-z undefs` flag to ld, however we should find out why those symbols are undefined.
Well, they are undefined because for some reason the _ctypes module is not explicitly linked against -ldl.
As I cannot reproduce this with the recent master branch from cpython (and my refactored libxcrypt patch applied), I think this has been fixed there already or is caused for some obscure reason to me from one of the other patches applied in Fedora.
Anyways, I've added a patch to explicitly link the _ctypes module against -ldl in the mean time and it builds fine with that and _strict_symbol_defs_build defined as usual.
Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=24396265
(In reply to Björn 'besser82' Esser from comment #1)
> As I cannot reproduce this with the recent master branch from cpython (and
> my refactored libxcrypt patch applied)
I can reproduce after upgrading `redhat-rpm-config` *and* re-exporting the new `LDFLAGS`. Even more modules are failing there, because of changing to linking with strict symbols defs.
Does Python still capture the compiler/linker flags used when the package was built? That's bad.
In any case, yes, ctypes needs to be linked with -ldl. Considering that Python modules are expected to be linked against the Python run-time DSO, I think it would be prudent to enforce -z defs for Python modules. In general, this is absolutely required to generate the proper RPM dependencies for Python modules, and lack of relevant DT_NEEDED entries can also cause problems with dynamic linking due to incorrect relocation order.
Will follow up with upstream on this.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.
Tested the upstream fix by enabling the strict symbol check through a macro  since the flag has been reversed now.
 %define _strict_symbol_defs_build 1
ctypes compiled successfully with no issues so I pushed the fix for master and F28.