gh-151422: Don't link libffi into _ctypes_test.so - #151423
Conversation
295fabb to
4fb91c5
Compare
freakboy3742
left a comment
There was a problem hiding this comment.
This makes sense; one question inline about the skip strategy.
The only question is about why libffi was linked in the first place. It appears to have been introduced in #120894, but I can't see any reason why it would have been (other than oversight/overenthusiasm that didn't hurt anything at the time).
That patch was included in the development of 3.14; you've flagged this for 3.15 back porting - can you think of any reason this shouldn't be backported to 3.14 as well?
No, I'll add that. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
Thanks @hoodmane for the PR, and @freakboy3742 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14, 3.15. |
|
GH-151516 is a backport of this pull request to the 3.15 branch. |
|
GH-151517 is a backport of this pull request to the 3.14 branch. |
_ctypes_test doesn't use libffi directly, and linking it into the module causes emscripten tests to fail.

Minor build fix. This makes the ctypes tests run on Emscripten.
There is a bug in the Emscripten dynamic loader that caused any dynamic library that links libffi to fail to load. _ctypes_test.so unnecessarily links libffi so it would fail to load and tests that needed it were skipped.
There are two test failures behind that: one involving stack overflows which we have to skip as usual, and one that assumes that the abi for a function that takes a single struct with two doubles is the same as the abi for a function that takes two double arguments. This is not true in webassembly so we skip the test.