Look for fesetround in libm rather than the executable

[Keno]

We usually get lucky because GCC's runtime library includes this functions.
However, their proper place is in the math library and Clang's runtime
library does not include these functions on windows, so without this change
the function is not found.

Also bump openlibm to include the latest changes that make openlibm
work with clang on windows.

[tkelman]

is this a tag? delete the old checksums

[tkelman]

we statically link libm into the executable on windows for this kind of thing

[StefanKarpinski]

we statically link libm into the executable on windows for this kind of thing

Still, this is more correct and does no harm, so we should do it, no?

[tkelman]

Separately from a version change maybe. We should only be using a tagged version of openlibm, and Viral had a PR not that long ago that also upgraded openspecfun.

Isn't some of the floating point environment controlled on a per shared library basis? Rearranging bootstrap to move the os dependent parts so much earlier is also a little unfortunate.

[Keno]

@ViralBShah Can we tag a new openlibm version? It would be nice if windows build out of the box.

[vtjnash]

We usually get lucky because GCC's runtime library includes this functions.
However, their proper place is in the math library and Clang's runtime
library does not include these functions on windows, so without this change
the function is not found.

this isn't entirely true. on windows, iirc, it is usually provided as a statically linked file by the CRT. But my recollection was that we were actually providing this as an export from libjulia.dll and ./julia, due to our static linking to libopenlibm (which declares them DLLEXPORT).

[vtjnash]

Executed in 7e8f2c0 (#36588)