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