The implementation of `fesetenv` cannot be portable, as the value of
`FE_DFL_ENV` differs between platforms. On FreeBSD, it is a actual
environment. With glibc however, it's a sentinel -1 handled in the
implementation of its floating point functions.
With openlibm based on FreeBSD's libm, it assumes `FE_DFL_ENV` to be an
actual environment. That assumption breaks using code that was compiled
against glibc, e.g., `libcuda`:
```
Thread 1 "julia-debug" received signal SIGSEGV, Segmentation fault.
0x00007ffff7b855d0 in fesetenv () from /home/tim/Julia/julia/build/release/usr/bin/../lib/libopenlibm.so
(gdb) bt
```
This reverts commit 5a27b4c0c0.
Fixes https://github.com/JuliaLang/julia/issues/38427.
Win32 has been using a hack to switch the `fenv` functions from `static`
to `DLLEXPORT`, we apply that hack to all platforms that do not use a
host `fenv.h`.
I grepped through the FreeBSD source tree and for me, it seems to be
totally unclear why these two specific functions are weak references.
Such a construct is commonly used by FreeBSD's threading library
(libthr) to override certain functions, but I can't find any traces of
that.
Just use the function name directly. This fixes a compiler warning as
well (-Wmissing-prototypes).
Put external headers before internal ones. While there, replace a lot of
occurences of "openlibm.h" with <openlibm.h>. It should be thought of as
an external header, as it is installed along with the library.
OpenLibm has an implementation of fenv.h internally. This may be
problematic in case you want it to build against the host system's
implementation, as it would require you to somehow take the fenv.h file
out of the compiler search path.
Simply use a different naming scheme, similar to openlibm.h and
openlibm_complex.h. If we want to build against the host's fenv.h, we
can simply add an '#include <fenv.h>' from within this header.
Tim Besard