Sure, attached is a patch for the usock problem. But hm, this was against the 0.1 release, should I do it against the trunk?Regarding the patching of configure script, there must be something wrong with the automake (or is it autoconf) on this machine. The logic for setting NN_HAVE_EVENTFD works, and the logic for NN_USE_EVENTFD seems ok. But even though it correctly finds that eventfd doesn't exist on the system, it still sets NN_USE_EVENTFD.
AS_IF([test x"$ac_cv_func_eventfd"=xyes], [
AC_DEFINE([NN_USE_EVENTFD])], [
AS_IF([test x"$ac_cv_func_pipe"=xyes], [
AC_DEFINE([NN_USE_PIPE])], [
AS_IF([test x"$ac_cv_func_socketpair"=xyes], [
AC_DEFINE([NN_USE_SOCKETPAIR])], [
AC_MSG_ERROR([No signaling supported])
])
])
])
As expected, $ac_cv_func_eventfd has value "no".
/André
On 2013-09-17 09:40, Martin Sustrik wrote:
Hi Andre, Would you mind providing a patch? Martin On 17/09/13 09:29, André Jonsson wrote:On 2013-09-16 16:29, Martin Sustrik wrote:On 16/09/13 16:13, André Jonsson wrote:I can see that on my own (linux) machine that iov_base is a void *, howdoes that work? I mean, is the code in usock_posix.inc not used then?It is used. No idea why it compiles. In any case the line should look something like this: ((uint8_t*) hdr->msg_iov->iov_base) += nbytes; Does that help? MartinHm... I thought I replied to this already, but I can't find it... oh well.It does indeed help! The whole thing compiled like a charm (save for a handful of warnings).However, I had to do add an extra level of indirection for it to compile:*((uint8_t**)&(hdr->msg_iov->iov_base)) += nbytes; Which is horrible... but without it, it said: CC src/aio/usock.lo "src/aio/usock_posix.inc", line 901: error #2137: expression must be a modifiable lvalue ((uint8_t*)hdr->msg_iov->iov_base) += nbytes; Anyway, I'll see if I can make some adjustments to configure.ac for it to generate to correct defines for this platform (and hopefully not break it for others). /André
Attachment:
nanomsg_usock_posix_iov.patch.gz
Description: application/gzip
