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. -- Janne Blomqvist
