From: Willem Jan Withagen <wjw@digiware.nl>
To: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Getting cython to define ENODATA on FreeBSD. (Was: Re: [ceph] pybind: move cephfs to Cython (#7745))
Date: Mon, 29 Feb 2016 14:26:58 +0100 [thread overview]
Message-ID: <56D44722.6000801@digiware.nl> (raw)
In-Reply-To: <56D446DD.1020302@digiware.nl>
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
parent reply other threads:[~2016-02-29 13:27 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <56D446DD.1020302@digiware.nl>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56D44722.6000801@digiware.nl \
--to=wjw@digiware.nl \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.