Re: CVS commit: src/tests/lib/libm

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Wed, Jul 26, 2017 at 03:24:16 +0000, Taylor R Campbell wrote:

> > Date: Wed, 26 Jul 2017 00:31:48 +0300
> > From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
> > 
> > On Tue, Jul 25, 2017 at 21:29:33 +0000, coypu%sdf.org@localhost wrote:
> > > On Tue, Jul 25, 2017 at 09:26:56PM +0000, Valeriy E. Ushakov wrote:
> > > > Revert previous as it breaks at least sparc and hpcsh builds.
> > > > nearbyint() is not included in libm on all platforms.
> > > 
> > > The intention was to find which platforms do not install it and change
> > > them to install it
> > 
> > You can do that in your tree, not in the public repo.
> 
> I suggested to he@ that he commit this so we can quickly find which
> platforms have obviously broken libm, since nobody at the time had the
> resources to try every platform locally.

Get representative base.tgz extract libm and do nm on it on ~anything?
You don't even need tools built for that.

Also, portmasters could have been asked in advance, at least pro
forma.  If I'm given a heads up and a summary of what needs to be
done, I can usually schedule it within a few days.  When I see a
commit out of the blue that breaks several ports, I naturally assume
the author might not have relaized they are breaking things.  Stuff
like that happens, no big deal.  And then it's safer to revert the
commit temporarily than to second-guess.


> If you know about sparc and/or hpcsh, can you fix them by adding the
> right source file in the appropriate place in the libm Makefile?

If I know *what* about sparc and sh3? :)

I'm happily clueless about libm.  If nobody tells me what they want, I
can't help.  Also, with all the hand-wringing about our libm being
completely broken I'd expect there's at least a high-level summary of
what is broken or missing.  Or would you rather spring those surprises
on us one function at a time? :)

-uwe