Re: [PATCH 0/3]: Add math support for non LDBL_EQ_DBL architecture

Corinna Vinschen <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
On Apr  5 10:44, Joel Sherrill wrote:
> On Wed, Apr 5, 2023 at 4:23 AM Corinna Vinschen <[email protected]> wrote:
> > I noticed that you exclude Cygwin from the new code, which makes sense
> > as long as we provide our own long double math taken from Mingw-w64.
> 
> What needs to happen for Cygwin/Mingw_w64? Honestly, we didn't discuss
> that at all.

Not sure I understand the question.  After the patch, Cygwin should
just still work.  Mingw-w64 isn't supported by newlib.  What do you
mean?

> > However, there's something not quite right.  When trying to build I get
> > symbol conflicts for the fdim{f,l} and scalbln{f,l} symbols in the link
> > stage (paths shortend for readability):
> > [...]
> 
> We chatted and those will be fixed in the next round.

Thanks.

> Anything else you think needs tidying up?

Well, yes.  The patch introduces a new header <sys/endian.h>.  Cygwin
already maintains an <endian.h> header, as on Linux.

The way we install header files is that first, the newlib headers are
installed, and then, second, Cygwin headers are installed, thus
overriding newlib headers with Cygwin headers as required.  We have to
maintain <endian.h> for userspace compatibility, but after the
installation user will find two different versions of endian.h,
one in /usr/include, one in /usr/include/sys.

Would it make a lot of problems to move <sys/endian.h> to <endian.h>?


Thanks,
Corinna
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.