Am 24.01.24 um 10:13 schrieb Janne Blomqvist:
On Wed, Jan 24, 2024 at 10:28 AM FX Coudert <fxcoud...@gmail.com> wrote:
Now, if
the OS adds cospi() to libm and it's in libm's symbol map, then the
cospi() used by gfortran depends on the search order of the loaded
libraries.
We only include the fallback math functions in libgfortran when they are not
available on the system. configure detects what is present in the libc being
targeted, and conditionally compiles the necessary fallback functions (and only
them).
Exactly. However, there is the (corner?) case when libgfortran has
been compiled, and cospi() not found and thus the fallback
implementation is included, and then later libc is updated to a
version that does provide cospi(). I believe in that case which
version gets used is down to the library search order (i.e. the order
that "ldd /path/to/binary" prints the libs), it will use the first
symbol it finds. Also, it's not necessary to do some ifdef tricks
with gfortran.map, if a symbol listed there isn't found in the library
it's just ignored. So the *pi() trig functions can be unconditionally
added there, and then depending on whether the target libm includes
those or not they are then included in the exported symbol list.
It's possible to override this to look for specific symbol versions
etc., but that probably goes deep into the weeds of target-specific
stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or
something else?). I'm sure you don't wanna go there.
Isn't this something that could be addressed by
__attribute__(__weakref__)?
