Closed notwa closed 2 years ago
I was curious what CPython was doing with this mess and apparently it has in-house implementations for a handful of the "weirder" math functions - including gamma
(and apparently the reason gamma
is missing from Musl is because no one can agree on what function it's actually supposed to implement, so it was dropped from standards considerations).
it's certainly an option to omit the binding altogether. I'm fine with whatever.
I dropped math.gamma
and have math.lgamma
and math.tgamma
bound to their libc counterparts, for consistency with the rest of the math
module. For things that expect math.gamma
(eg., ported Python code), math.gamma = math.tgamma
should suffice, and I could bind that alias but have opted not to for now.
I was able to use musl-gcc
to build against musl without issue and passed the test suite.
Following the CPython approach, when I replace the stubbed versions of these functions in ToaruOS, the tgamma
implementation can be included in Kuroko, but for now it seems all of the real-world targets have at least lgamma
and tgamma
these days.
more fun times with detecting the existence of this function…
this issue prevents the math module from being imported — but let it be known that, after omitting the gamma function, all of kuroko's tests pass with musl! I threw together a Dockerfile running Alpine Linux for testing purposes.
note that musl does implement lgamma (and tgamma), but not gamma. infamously, musl does not define any macros for detection. however, we can exploit a leaked
#define
frommath.h
that's existed since 2012.I did a quick google search to see if any non-musl code is defining
__NEED_double_t
. it seems that all the results are either forks of musl, or LLVM defining__need_double_t
(all lowercase), so I don't think there'll be conflicts with other libc's.at least, that's my suggestion. I'll leave the final implementation up to you.