Broken library functions, especially on windows

Hello!

I come to you today seeking advice. I have recently filed two bugs
describing perl crashes or test failures due to broken math functions. One
involves powl() on mingw.org platforms ([0], upstream at [1]), and the
other involves modfl() on mingw-w64 x86_64 platforms ([2], upstream at [3]).

This is ultimately a problem because there's no Configure script on
Windows. Probably because there's no way to make a truly portable one. But
as a result, while we would check these library functions and refuse to
build with long doubles if we encountered this on a platform that uses
Configure, I'm not sure how to handle it on Windows.

One option is to replace those functions if needed. For example, I tried to
pull a working powl() into perl to solve the first bug. It /mostly/ works,
(miniperl builds, and the problem is fixed), but there are two problems.
First, the build fails in ext/POSIX for reasons I don't understand.
(patch[4], build log[5]) Second, this seems like a very heavy-handed
"solution".

This solution involves finding a working implementation, bringing it into
the perl core for eternity, and #if-guarding it - for now, for the current
MinGW API version, and in the future, changing that to only the range of
broken versions, if and when the upstream bug is fixed. We never get to
remove this bloat from core, and as I'm not a high-precision math guru, I
can't vouch for the correctness of this code, either now or in the future:
only that it is better at passing tests than the version that shipped with
MinGW.

I'd feel somewhat better about this solution if someone could help me
figure out why it won't build cleanly. If so, I'd be happy to work on a
similar patch for the modfl() problem. It should be easier because there is
a patch in the upstream ticket.

Another option is to skip or todo those tests. This also seems poor form,
since we're basically admitting that our program doesn't work, but saying
"not my fault, not my problem".

We could leave the tests failing, or we could refuse to build with long
doubles on these MinGW(?:-w64)? versions. The former is confusing - the
user doesn't know /what/ failed, only that /something/ did - and the
modfl() failure isn't even clear - there's no mention of modfl in the build
log, only that the test exited after test 28, and that no plan was found.
The latter may also be heavy-handed, especially if we're gating on MinGW
version rather than on an actual test that says something is broken.

So, do we:
1) Replace the offending functions with our own? (can anyone tell me why my
build is failing?)
2) TODO the tests, unless they crash the test script, in which case skip
them?
3) Take no action?
4) Refuse to enable long doubles on known-broken platforms?

Thanks,

--
Dan Collins

[0]: https://rt.perl.org/Ticket/Display.html?id=128643
[1]: https://sourceforge.net/p/mingw/bugs/2306/
[2]: https://rt.perl.org/Ticket/Display.html?id=128673
[3]: https://sourceforge.net/p/mingw-w64/bugs/478/
[4]: https://gist.github.com/dcollinsn/fc242bc7a7c31664259f9a296b66c605
[5]: https://gist.github.com/dcollinsn/1b5f00ac34b392df25179bd36c2632d2

• Broken library functions, especially on windows by Dan Collins
• Re: Broken library functions, especially on windows by bulk88
• Re: Broken library functions, especially on windows by Dan Collins