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
