ENH, BLD: Fix math feature detection for wasm #21277
Merged
+220
−23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The web assembly linker is strict about function types, it is unwilling to link a function defined with signature say `double f(double, double)` to an invocation with signature `void f(void)`. This causes trouble in `numpy/core/setup.py` in the functions `check_math_capabilities` and `check_mathlib`. This patch fixes the problem by giving config.try_link the correct function signatures for these functions. In particular I added a separate header file with all the math declarations. It would be be possible to just include 'math.h' but we also need to parse the declarations to figure out how to call the functions. If f has arguments type1, type2, type3, we want to call it like f((type1)0, (type2)0, (type3)0). Anyways it is easier to parse the arguments out of our feature_detection_math.h than to worry about the possibility that someone will have a differently formatted system math.h. We do a test where we include both math.h and feature_detection_math.h to ensure consistency between the signatures. I also separated out the fcntl functions, backtrace and madvise, and strtold_l. This is because they require separate headers. strtold_l requires testing both with the locale.h header and with the xlocale.h header (this seems to vary even among different linuxes). All of the functions I moved out of OPTIONAL_STDFUNCS are absent on windows and some are absent on OSX so separating them out of the OPTIONAL_STDFUNCS should mildly improve the speed of feature detection on mac and windows (since they have all the functions remaining in OPTIONAL_STDFUNCS).
charris
added
01 - Enhancement
08 - Backport
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #21254.
The web assembly linker is strict about function types, it is
unwilling to link a function defined with signature say double
f(double, double) to an invocation with signature void f(void). This
causes trouble in numpy/core/setup.py in the functions
check_math_capabilities and check_mathlib.
This patch fixes the problem by giving config.try_link the correct
function signatures for these functions. In particular I added a
separate header file with all the math declarations. It would be be
possible to just include 'math.h' but we also need to parse the
declarations to figure out how to call the functions. If f has
arguments type1, type2, type3, we want to call it like f((type1)0,
(type2)0, (type3)0). Anyways it is easier to parse the arguments out
of our feature_detection_math.h than to worry about the possibility
that someone will have a differently formatted system math.h. We do a
test where we include both math.h and feature_detection_math.h to
ensure consistency between the signatures.
I also separated out the fcntl functions, backtrace and madvise, and
strtold_l. This is because they require separate headers. strtold_l
requires testing both with the locale.h header and with the xlocale.h
header (this seems to vary even among different linuxes). All of the
functions I moved out of OPTIONAL_STDFUNCS are absent on windows and
some are absent on OSX so separating them out of the
OPTIONAL_STDFUNCS should mildly improve the speed of feature
detection on mac and windows (since they have all the functions
remaining in OPTIONAL_STDFUNCS).