[Cython] Cygwin: Handling missing C99 long double functions

[Robert Bradshaw]

On Tue, Apr 26, 2016 at 8:36 AM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Tue, Apr 26, 2016 at 5:16 PM, Dima Pasechnik
> <dimpase+github at gmail.com> wrote:
> > Hi,
> > certainly we did something with Sage on cygwin to work around these...
> > Just in case,
>
> From what I can tell there are several places where Sage has hacked
> around this issue in different packages, but it's not doing anything
> specifically with it for Cython.  Sage uses the Cephes math lib to
> support these functions on FreeBSD--and apparently used to use it on
> Cygwin too, but disabled that for some reason.
>
> Regardless, Cython should ultimately do something sensible in these cases.
>
> My general thinking is that in cases where Cython generates code
> containing C math functions, it ought to support a fallback.  This
> will require some feature checks so that Cython can generate wrappers,
> when necessary, around the double versions of those functions (as
> Numpy currently does).
>

Let's make things concrete. You're complaining that something like

cdef extern from "math.h":
    long double sqrtl(long double)

def foo(long double x):
    return sqrtl(x)

Doesn't work on Cygwin?

The same is true for *any* C function that you use that's not totally
portable (this is the bane of trying to use C). I don't think Cython should
be detecting this and substituting a (less accurate) sqrt for sqrtl in this
case. If you want do do this, write your own headers that (conditionally)
define these things however you want.

Or, are you complaining that Cython's test suite doesn't pass on some
Cygwin because there are tests of features not available on Cygwin? (Your
original email isn't clear.) If so, the test framework can be set up to
exclude these tests on that platform.


>
> Erik
>
> > On Tue, Apr 26, 2016 at 3:58 PM, Erik Bray <erik.m.bray at gmail.com>
> wrote:
> >> Hi again,
> >>
> >> Sorry if I'm spamming the list too much, but I've encountered another
> >> pretty serious and unfortunate issue with Cython on Cygwin.
> >>
> >> The problem now is that many of libm long double functions like sqrtl,
> >> tanl, etc. are missing on Cygwin (missing from newlib to be specific).
> >> I think this is a previously known issue, but nothing's ever really
> >> been done about it.  Well, to be clear, sometimes they're present, but
> >> only when sizeof(double) == sizeof(long double).  However on 64-bit
> >> Cygwin sizeof(long double) == 16, so the functions are simply not
> >> defined.
> >>
> >> This seems to be due to lack of interest / effort:
> >> https://www.cygwin.com/ml/cygwin/2011-04/msg00231.html  That post is 5
> >> years old, but I can't find any evidence that this has changed.
> >>
> >> There are quite a few tests in Cygwin's test suite that test long
> >> double support.  I guess what I'm asking is what would be the best
> >> thing to do about it.
> >>
> >> I could just skip those tests on Cygwin, though I'm not sure the best
> >> way to go about skipping an entire test for a given platform.
> >>
> >> More generally though, outside the context of testing, this means
> >> Cygwin will sometimes generate code that cannot be compiled on this
> >> platform, and a question arises as to what to do about that.  I have
> >> some thoughts, but am not sure if it's worth discussing any further or
> >> not.
> >>
> >> Thanks,
> >> Erik
> >> _______________________________________________
> >> cython-devel mailing list
> >> cython-devel at python.org
> >> https://mail.python.org/mailman/listinfo/cython-devel
> > _______________________________________________
> > cython-devel mailing list
> > cython-devel at python.org
> > https://mail.python.org/mailman/listinfo/cython-devel
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160426/b2dbd1a5/attachment.html>