This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Source file structure for fenv.h support
On Tue, Jul 30, 2019 at 6:00 PM Howland, Craig D. - US <
craig.howland@caci.com> wrote:
> ------------------------------
> *From:* Joel Sherrill <joel@rtems.org>
> *Sent:* Tuesday, July 30, 2019 6:21 PM
> *To:* Howland, Craig D. - US
> *Cc:* newlib@sourceware.org
> *Subject:* Re: Source file structure for fenv.h support
>
> On Tue, Jul 30, 2019 at 1:35 PM Howland, Craig D. - US via newlib <
> newlib@sourceware.org> 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
>
>