[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-devel
Subject:    Re: Getting cython to define ENODATA on FreeBSD. (Was: Re: [ceph] pybind: move cephfs to Cython (#77
From:       Willem Jan Withagen <wjw () digiware ! nl>
Date:       2016-02-29 13:26:58
Message-ID: 56D44722.6000801 () digiware ! nl
[Download RAW message or body]

On 29-2-2016 12:57, Mehdi Abaakouk wrote:
> Hi,
> 
> Le 2016-02-29 11:27, Willem Jan Withagen a écrit :
>> Hi,
>>
>> You write:
>>
>> If you have errno.pxd, and cimport won't work, perhaps that means you
>> have something wrong with your cython package. Cython/Includes/libc is
>> automatically included on Linux for cython compilation and it looks not
>> on FreeBSD.
>>
>> But probably is one of the  issues that lies ahead of this, is the fact
>> that in
>>     /usr/include/errno.h FreeBSD does not define ENODATA.
>> And thus during compilation that value is not known (anywhere)
>>
>> In most of the Ceph code it is replaced by ENOATTR.
> 
>> I did not picked that but others that did work before me. And whatever
>> choice you make it is going to break somewhere nayways.
>>
>> Now the question here is going to be how to educate cython to actually
>> pickup on this change....
>> Perhaps by adding an extra include that "overlays" the current one and
>> adds errno.ENODATA to the errno enum?
>>
>> I do not know enough of python/cython how to do that, or that it is even
>> possible?
> 
> If a Cython headers (*.pyd) have ENODATA, you need to fix it.
> 
> So, the only good solution for that is fixing cython for FreeBSD, I
> don't see why you would add crap in Ceph here.
> 
> I'm sure the FreeBSD community is open and aware about not existing
> ENODATA on their system, and regulary patch application to remove it.
> You just have to fix the FreeBSD Cython Package (or even upstream Cython
> if they officially support FreeBSD).

Hi,

I'm a member of the FreeBSD community since 1993. :)

The reason that it is not in FreeBSD is might be  because the standard
does not require it. :(

------
IEEE Std 1003.1 2004 says that ENODATA is an 'XSR' extension:

"The functionality described is optional. The functionality described is
also an extension to the ISO C standard."

ENODATA appears to be mandatory.
-------

And as such it might be, might not be able to get it into the FreeBSD
include files. However that will take a long time, and during that time
I will not be able to complete the tests required to run all tests for
FreeBSD.

And as such is the 'crap' you refer too, a consequence of using
extensions to the standard for software, thus hampering the portability.
Uptil now I've been able to tackle just about all the issues.
And if I remember correctly this one wasn't an issue in my previous
testruns until the python piece got ripped out, and replaced with cython.

So I you ( or anybody else on this list) know(s) any ways to keep me
going with porting I'd be very thankful.

--WjW

I will also try to raise the issue in the FreeBSD lists.



--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]