root@Zomatrees:~/libevent# sh autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force configure.ac:129: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1
-dlfor libssl/libcrypto, but we need do this for autoconf and cmake, and also as a generic solution not for
Hi is there any official support for IBM AIX? I managed to get it to build on AIX 7.1 but had to comment out
#define _LARGE_FILES 1
in event2/event-config.h line 524. Otherwise build fails with:
In file included from sample/signal-test.c:15:0:
/opt/freeware/lib/gcc/powerpc-ibm-aix188.8.131.52/6.3.0/include-fixed/unistd.h:210:16: error: conflicting types for 'lseek64'
extern off64_t lseek64(int, off64_t, int);
/opt/freeware/lib/gcc/powerpc-ibm-aix184.108.40.206/6.3.0/include-fixed/unistd.h:208:14: note: previous declaration of 'lseek64' was here
extern off_t lseek(int, off_t, int);
In file included from /opt/freeware/lib/gcc/powerpc-ibm-aix220.127.116.11/6.3.0/include-fixed/unistd.h:866:0,
/usr/include/sys/lockf.h:64:13: error: conflicting types for 'lockf64'
extern int lockf64 (int, int, off64_t);
/usr/include/sys/lockf.h:62:13: note: previous declaration of 'lockf64' was here
extern int lockf (int, int, off_t);
and similar errors.
I have access to some AIX boxes running AIX 7.1 and gcc 6.3.0. I'm interested in bugfixing/testing to make it work.
#undef _LARGE_FILESwhile cmake has
#cmakedefine _LARGE_FILES 1and this is different
I'm using libevent on Linux (different kernel versions and architectures).
While looking into the output of an strace command, I observed that epoll_wait was called a lot of times with a very short timeout (1 or 2ms) while we do not have such a small timers running and no events were received on the registered FDs.
After adding some traces I observed that in some cases, the epoll_wait times-out and when handling the timers afterwards, not any timer was not expiring yet because "now" was bigger than the timeout value of the first timer.
After further code-study I came to the conclusion that the root-cause of this behavior was the CLOCK_MONOTONIC_COARSE clock. By passing the flag EVENT_BASE_FLAG_PRECISE_TIMER to my baseloop to use CLOCK_MONOTONIC instead my problem seems to be resolved. But in this configuration also the timerfd is used, which is not what I want. I only want to use the CLOCK_MONOTONIC instead of CLOCK_MONOTONIC_COARSE.
I tested this by commenting out the timerfd feature and the problem is also solved.
Now the question is: why is EVENT_BASE_FLAG_PRECISE_TIMER combining both the use of CLOCK_MONOTONIC and timerfd? Would it not be more logical to have 2 configuration flags?