[PATCH/QUESTION] newlib: fenv: AArch64 Cygwin linking fixes

[Corinna Vinschen]

On Jun 23 16:36, Richard Earnshaw (lists) wrote:
> On 16/06/2025 12:31, Radek Barton wrote:
> > Hello.
> > 
> > This is more a question than patch submission: Without the attached changes, the Cygwin cannot be linked for AArch64 failing on:
> > ```
> > ld: cannot export _fe_nomask_env: symbol not defined
> > ld: cannot export fedisableexcept: symbol not defined
> > ld: cannot export fegetexcept: symbol not defined
> > ld: cannot export fegetprec: symbol not defined
> > ld: cannot export fesetprec: symbol not defined
> > ```
> > Can anybody share some insights why are those changes needed and whether there is a better way how to overcome this issue?
> > 
> > Note that the `feenableexcept`, `fedisableexcept`, `fegetexcept` implementations are similarly defined in `newlib/libc/machine/mips/machine/fenv-fp.h` for MIPS architecture as well.
> > 
> > Thank you,
> > 
> > Radek
> > 
> 
> Ugh, this is a real rat's nest of code...
> 
> I may be on completely the wrong track, but I think the clue is in the comment:
> 
>  +/* We currently provide no external definitions of the functions below. */
> 
> So it is expected that these functions have no definition in a file, but will be inlined into the calling code when needed.  This is why they are provided in fenv.h.  fenv-fp.h seems to be the internal header that is used for code that will create the non-inlined versions; the header file fenv-fp.h isn't exported from the library though (it's only used while building it), so anything defined there will never be inlined into user code.
> 
> I suspect that the underlying issue is that coff libraries rely on
> explicitly exporting symbols, while ELF libraries do that implicitly
> (unless something is explicitly marked hidden).

I wonder if this is really the issue, because binutils ld performs
its auto-export magic for coff symbols for ages on Cygwin.  Unless
you define exactly the symbols to export in a .def file, that is.

However, Cygwin's .def file explicitly exports the above fe* symbols.

They are just not actually present in the object files in case of the
aarch64 build per Radek.


> What I don't fully understand is what role __BSD_VISIBLE might have
> here.  If that's not defined (which I'd think is possible in CYGWIN),

Only for applications built under Cygwin, but not for building the Cygwin
DLL itself, which is the problem here.

> then I can't see how your changes would resolve this.
> 
> I'm guessing (somewhat) that libm/.../fenv.c should perhaps define __BSD_VISIBLE before including fenv.h to force the inline functions to become visible. 
> 
> The other alternative might be to remove the list of functions scoped by the ifdef from libm/machine/aarch64/fenv.c so that the functions that file exports matches the comment I mentioned above.
> 
> Perhaps you could try this patch instead of yours and let me know if it resolves the issue:
> 
> diff --git a/newlib/libm/machine/aarch64/fenv.c b/newlib/libm/machine/aarch64/fenv.c
> index 3ffe23441..fb6a67dcc 100644
> --- a/newlib/libm/machine/aarch64/fenv.c
> +++ b/newlib/libm/machine/aarch64/fenv.c
> @@ -27,6 +27,9 @@
>   * $FreeBSD$
>   */
>  
> +/* Enable all fenv-related functions.  */
> +#define __BSD_VISIBLE
> +
>  #define        __fenv_static
>  #include <fenv.h>
>  #include <machine/fenv-fp.h>

Worth a try.


Thanks,
Corinna