Re: Source file structure for fenv.h support

Joel Sherrill <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <CAF9ehCUzD1D7U=5Aox7Y7Aciz4EJ1+T0cdO8K287zXvZ4u_8QA@mail.gmail.com>
On Tue, Jul 30, 2019 at 6:00 PM Howland, Craig D. - US <
[email protected]> wrote:

> ------------------------------
> *From:* Joel Sherrill <[email protected]>
> *Sent:* Tuesday, July 30, 2019 6:21 PM
> *To:* Howland, Craig D. - US
> *Cc:* [email protected]
> *Subject:* Re: Source file structure for fenv.h support
>
> On Tue, Jul 30, 2019 at 1:35 PM Howland, Craig D. - US via newlib <
> [email protected]> wrote
>
>> > ...
>> > Good idea. Put them in libm/math as individual files?
>>      New directory, libc/fenv, would follow present convention.  Yes,
>> individual files to make both for less overhead when linking as well as
>> being easier to replace each placeholder function with a real one.
>>
>>
> > I question libc/fenv since these are supposed to be in libm but agree
> > on a new subdirectory
>
> In libm is fine with me if they are supposed to be there, but who says
> libm?
>

:)

The stubs will also be a good place to put documentation.


> (I've never seen a definition allocating where.  POSIX doesn't seem to
> that I can find.  The Linux man pages do show -lm needed, so past
> convention is a suitable reason, but I'm curious as to if there is a
> "standard" that defines the mapping of C and/or POSIX functions to a
> library name.  I expected to find it in POSIX and was surprised not to.)
>

I've never seen it either. -lrt and -lpthread are also common but I don't
know of a requirement for them. RTEMS doesn't make that separation.

--joel


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