Date: Fri, 1 Jun 2012 03:17:44 -0400 From: "b. f." <bf1783@googlemail.com> To: freebsd-current@freebsd.org Cc: Stephen Montgomery-Smith <stephen@missouri.edu> Subject: Re: Use of C99 extra long double math functions after r236148 Message-ID: <CAGFTUwMSKnzY_qRse5yLi0cRSz0mNOLiyJvAy8qAmTt-PRKtpQ@mail.gmail.com> In-Reply-To: <CAGFTUwMSsjPf2SOT4nv%2BxoDgXjDBDKSoNqj9QNOjA2uiQ_4HWg@mail.gmail.com> References: <CAGFTUwMSsjPf2SOT4nv%2BxoDgXjDBDKSoNqj9QNOjA2uiQ_4HWg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I do think we should provide something in ports as an interim solution. > > There are other 3rd party applications looking to drop FreeBSD support > > because we are missing APIs that almost all other OS's have. I'm fine > > if the interim lives in ports and that we don't import substandard > > routines into the base. I would even be fine with calling it > > /usr/local/lib/libm_inaccurate.so. However, I do think we need an option. > > > > I think it should be called libm.so. Otherwise we have to do a serious > editing job on the Makefiles/configure scripts. I think that this is as it should be: only those applications that really need to link against such a library should do so, and this should be enforced and checked by the port maintainer. If you call it by the same name you still need to make other changes to ensure that the right library is used, and these other changes can be confusing and lead to problems, as with the openssl and gcc support libraries. Some portable applications already provide convenient variables in their build infrastructure, since the quality, coverage, and location of the math libraries varies on different systems. b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwMSKnzY_qRse5yLi0cRSz0mNOLiyJvAy8qAmTt-PRKtpQ>