=> Bootstrap dependency digest>=20010302: found digest-20111104 => Checksum SHA1 OK for EV-4.10.tar.gz => Checksum RMD160 OK for EV-4.10.tar.gz ===> Installing dependencies for p5-EV-4.10nb1 => Build dependency checkperms>=1.1: found checkperms-1.11 => Full dependency p5-common-sense-[0-9]*: found p5-common-sense-3.6 => Full dependency perl<5.18.0: found perl-5.16.1 => Full dependency perl>=5.16.0: found perl-5.16.1 => Full dependency libev>=4.01: found libev-4.04 ===> Overriding tools for p5-EV-4.10nb1 ===> Extracting for p5-EV-4.10nb1 ===> Patching for p5-EV-4.10nb1 ===> Creating toolchain wrappers for p5-EV-4.10nb1 ===> Configuring for p5-EV-4.10nb1 => Checking for portability problems in extracted files *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Welcome to EV configuration. If you are in a hurry, just press return here and hope for the best. The defaults should usually do. Skip further questions and use defaults (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** POSIX optionally offers support for a monotonic clock source. EV can take advantage of this clock source to detect time jumps more reliably. Unfortunately, some systems are bound to be broken, so you can disable this here: you can completely disable the detection and use of the monotonic clock by answering 'n' here. Support for this clock type will otherwise be autodetected at both compile- and runtime. (this setting currently affects the use of nanosleep over select as well). Enable optional support for CLOCK_MONOTONIC (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** POSIX optionally offers support for a (potentially) high-resolution realtime clock interface. In a good implementation, using it is faster than the normal method of using gettimeofday. Unfortunately, this option is also bound to be broken on some systems, and current EV versions do not actually call gettimeofday very often, so it defaults to no. Prefer clock_gettime (CLOCK_REALTIME) over gettimeofday (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** EV can use various backends with various portability issues. The select backend is the most portable and makes for a good fallback, but it can be limited to a low number of file descriptors and/or might not compile. If you have problems with compiling ev_select.c, you might try to play around with disabling it here, or forcing it to use the fd_set provided by your OS, via the next question. I highly recommend keeping it in. Enable select backend (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** The select backend can operate in two modes. One uses the system-provided fd_set and is usually limited to 1024 file descriptors (64 on windows), the other requires your header files to define NFDBITS and declare a suitable fd_mask type. If you run into problems compiling ev_select.c, you can try forcing the use of the system fd_set here. Force use of system fd_set for select backend (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** The second very portable backend is poll(2). It does not exist on windows and various versions of Mac OS X (and on the other versions it simply doesn't work), but works basically everywhere else. It is recommended to use the default here unless you run into compile problems in ev_poll.c. Enable poll backend (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Select and poll make it hard to write efficient servers, especially if the number of active connections is much lower than the watched ones. GNU/Linux systems have a more scalable method called "epoll", which EV can use. For this to work, both your kernel and glibc have to support epoll, but if you can compile it, the detection will be done at runtime, and EV will safely fall back to using select when epoll isn't available. If unsure, accept the default. Enable epoll backend (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Similarly to the epoll backend above, EV can take advantage of kqueue on many BSD systems. Support for kqueue will be detected at runtime, with a safe fallback to other methods when it cannot be used. Note that kqueue is broken on most operating systems, so by default it won't be used on many platforms, but you can still create your own event loop with kqueue backend if you ask specifically for it. Here is what we know: NetBSD: partially working in at least 3.1 and later. Yeah! :) FreeBSD: broken on at least 6.2-STABLE, spotty in later versions, sockets *likely* work, ptys definitely don't. OpenBSD: reports indicate that it likely doesn't work (similar problems as on FreeBSD). OS X: completely, utterly broken on at least <= 10.6. Enable kqueue backend (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Similarly to the kqueue backend above, EV can take advantage of the solaris 10 event port interface. Support for event ports will be detected at runtime, with a safe fallback to other methods when it cannot be used. Enable event port backend (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** EV needs the functions pthread_atfork and clock_gettime. On most systems you need some special libraries for this (such as -lrt and -lpthread). You can specify additional libraries to provide these calls (and any other required by EV) now, or accept the default. Extra libraries for pthread_atfork and clock_gettime? [-lpthread -lrt ] -lpthread -lrt *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** A backend of a different kind is the Linux inotify(7) interface, which can be used to speed up (and reduce resource consumption) of stat watchers. If you have the include file and libc support for it, it is usually a good idea to enable it, as kernel availability is detected at runtime. Enable inotify support (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Another useful bit of functionality is the Linux eventfd, which is useful for faster signal handling (don't care) and intra-thread communications (more relevant). Kernel support for this will be probed at runtime, but your libc must contain the necessary wrapper. Glibc 2.7 and later should have this wrapper. Enable linux eventfd support (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Another sometimes useful bit of functionality is the Linux signalfd, which is useful for faster signal handling (don't care). Kernel support for this will be probed at runtime, but your libc must contain the necessary wrapper. Glibc 2.7 and later should have this wrapper. Enable linux signalfd support (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Very rarely, people want to tweak EV even more, e.g. to exclude or include certain watcher types or backends. This cna be done by adding extra -D options here, or via the EV_EXTRA_DEFS environment variable. Normal persons just press enter. Any extra -D options? [] *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Checking if your kit is complete... Looks good Note (probably harmless): No library found for -lrt Writing Makefile for EV Writing MYMETA.yml and MYMETA.json