Build of perl-ev with musl toolchain

# [tuscan]
# Server = file:///var/cache/pacman/pkg/

# :: Synchronizing package databases...
# downloading tuscan.db...

# /sysroot/lib
# /sysroot/share
# /sysroot/bin
# /sysroot/include
# /sysroot/libexec

# ==> Making package: perl-ev 4.22-2 (Wed Apr 5 01:54:48 UTC 2017)
# ==> Checking runtime dependencies...
# ==> Installing missing dependencies...
# resolving dependencies...
# looking for conflicting packages...
#
# Packages (1) perl-common-sense-3.74-1
#
# Total Installed Size: 0.00 MiB
#
# :: Proceed with installation? [Y/n]
# checking keyring...
# checking package integrity...
# loading package files...
# checking for file conflicts...
# checking available disk space...
# :: Processing package changes...
# installing perl-common-sense...
# :: Running post-transaction hooks...
# (1/1) Updating manpage index...
# ==> Checking buildtime dependencies...
# ==> Installing missing dependencies...
# resolving dependencies...
# looking for conflicting packages...
#
# Packages (1) perl-canary-stability-2011-2
#
# Total Installed Size: 0.07 MiB
#
# :: Proceed with installation? [Y/n]
# checking keyring...
# checking package integrity...
# loading package files...
# checking for file conflicts...
# checking available disk space...
# :: Processing package changes...
# installing perl-canary-stability...
# :: Running post-transaction hooks...
# (1/1) Updating manpage index...
# ==> WARNING: Using existing $srcdir/ tree
# ==> Starting build()...
#
# ***
# *** Canary::Stability COMPATIBILITY AND SUPPORT CHECK
# *** =================================================
# ***
# *** Hi!
# ***
# *** I do my best to provide predictable and reliable software.
# ***
# *** However, in recent releases, P5P (who maintain perl) have been
# *** introducing regressions that are sometimes subtle and at other times
# *** catastrophic, often for personal preferences with little or no concern
# *** for existing code, most notably CPAN.
# ***
# *** For this reason, it has become very hard for me to maintain the level
# *** of reliability and support I have committed myself to in the past, at
# *** least with some perl versions: I simply can't keep up working around new
# *** bugs or gratituous incompatibilities, and in turn you might suffer from
# *** unanticipated problems.
# ***
# *** Therefore I have introduced a support and compatibility check, the results
# *** of which follow below, together with a FAQ and some recommendations.
# ***
# *** This check is just to let you know that there might be a risk, so you can
# *** make judgement calls on how to proceed - it will not keep the module from
# *** installing or working.
# ***
# *** The stability canary says: (nothing, it was driven away by harsh weather)
# ***
# *** It seems you are running perl version 5.024000, likely the "official" or
# *** "standard" version. While there is nothing wrong with doing that,
# *** standard perl versions 5.022 and up are not supported by EV.
# *** While this might be fatal, it might also be all right - if you run into
# *** problems, you might want to downgrade your perl or switch to the
# *** stability branch.
# ***
# *** If everything works fine, you can ignore this message.
# ***
# *** Stability canary mini-FAQ:
# ***
# *** Do I need to do anything?
# *** With luck, no. While some distributions are known to fail
# *** already, most should probably work. This message is here
# *** to alert you that your perl is not supported by EV,
# *** and if things go wrong, you either need to downgrade, or
# *** sidegrade to the stability variant of your perl version,
# *** or simply live with the consequences.
# ***
# *** What is this canary thing?
# *** It's purpose is to check support status of EV with
# *** respect to your perl version.
# ***
# *** What is this "stability branch"?
# *** It's a branch or fork of the official perl, by schmorp, to
# *** improve stability and compatibility with existing modules.
# ***
# *** How can I skip this prompt on automated installs?
# *** Set PERL_CANARY_STABILITY_NOPROMPT=1 in your environment.
# *** More info is in the Canary::Stability manpage.
# ***
# *** Long version of this FAQ: http://stableperl.schmorp.de/faq.html
# *** Stability Branch homepage: http://stableperl.schmorp.de/
# ***
#
# Continue anyways? [y] y
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# 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)? [y] y
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# 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)? [n] n
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# 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.
#
# On GNU/Linux systems, EV uses the LSB 3.1 __register_atfork function
# to avoid the dependency on libpthread, and directly uses the clock_gettime
# syscall to avoid a dependency on librt.
#
# Extra libraries for pthread_atfork and clock_gettime? [ ]
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# 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)? [y] y
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# 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)? [y] y
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# 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)? [y] y
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# Very rarely, people want to tweak EV even more, e.g. to exclude
# or include certain watcher types or backends. This can be done by adding
# extra -D options here, or via the EV_EXTRA_DEFS environment variable.
#
# For example, if you run into compile problems because of missing memory
# fences (or you just want extra performance), you can tell EV to not support
# smp and threads via -DEV_NO_THREADS.
#
# Normal persons just press enter.
#
# Any extra -D options? []
#
# *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
#
#
# Checking if your kit is complete...
# Looks good
# Generating a Unix-style Makefile
# Writing Makefile for EV
# Writing MYMETA.yml and MYMETA.json
# Running Mkbootstrap for EV ()
# "/usr/bin/perl" "/usr/share/perl5/core_perl/ExtUtils/xsubpp" -typemap "/usr/share/perl5/core_perl/ExtUtils/typemap" -typemap "typemap" EV.xs > EV.xsc && mv EV.xsc EV.c
# chmod 644 "EV.bs"
# cp EV.pm blib/lib/EV.pm
# cp EV/EVAPI.h blib/lib/EV/EVAPI.h
# cp libev/ev.pod blib/lib/EV/libev.pod
# cp libev/ev.h blib/lib/EV/ev.h
# cp EV/MakeMaker.pm blib/lib/EV/MakeMaker.pm
# cc -c -Ilibev -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -DVERSION=\"4.22\" -DXS_VERSION=\"4.22\" -fPIC "-I/usr/lib/perl5/core_perl/CORE" -DEV_USE_REALTIME=0 -DEV_USE_SELECT=1 -DEV_USE_POLL=1 -DEV_USE_EPOLL=1 -DEV_USE_KQUEUE=0 -DEV_USE_PORT=0 -DEV_USE_INOTIFY=1 -DEV_USE_EVENTFD=1 -DEV_USE_SIGNALFD=1 EV.c
# In file included from EV.xs:11:
# ./schmorp.h:350:10: warning: implicit declaration of function 'fcntl' is invalid in C99 [-Wimplicit-function-declaration]
# return fcntl (fd, F_SETFL, blocking ? 0 : O_NONBLOCK);
# ^
# ./schmorp.h:350:45: error: use of undeclared identifier 'O_NONBLOCK'
# return fcntl (fd, F_SETFL, blocking ? 0 : O_NONBLOCK);
# ^
# ./schmorp.h:350:21: error: use of undeclared identifier 'F_SETFL'
# return fcntl (fd, F_SETFL, blocking ? 0 : O_NONBLOCK);
# ^
# ./schmorp.h:357:24: error: use of undeclared identifier 'F_SETFD'
# || fcntl (fd, F_SETFD, FD_CLOEXEC);
# ^
# ./schmorp.h:357:33: error: use of undeclared identifier 'FD_CLOEXEC'
# || fcntl (fd, F_SETFD, FD_CLOEXEC);
# ^
# In file included from EV.xs:40:
# In file included from ./libev/ev.c:169:
# /sysroot/include/fcntl.h:34:5: error: conflicting types for 'fcntl'
# int fcntl(int, int, ...);
# ^
# ./schmorp.h:350:10: note: previous implicit declaration is here
# return fcntl (fd, F_SETFL, blocking ? 0 : O_NONBLOCK);
# ^
# In file included from EV.xs:40:
# ./libev/ev.c:483:48: warning: '/*' within block comment [-Wcomment]
# /*#define MIN_INTERVAL 0.00000095367431640625 /* 1/2**20, good till 2200 */
# ^
# ./libev/ev.c:3848:34: warning: '&' within '|' [-Wbitwise-op-parentheses]
# fd_change (EV_A_ fd, w->events & EV__IOFDSET | EV_ANFD_REIFY);
# ~~~~~~~~~~^~~~~~~~~~~~~ ~
# ./libev/ev.c:3848:34: note: place parentheses around the '&' expression to silence this warning
# fd_change (EV_A_ fd, w->events & EV__IOFDSET | EV_ANFD_REIFY);
# ^
# ( )
# 3 warnings and 5 errors generated.
# make: *** [Makefile:354: EV.o] Error 1
# ==> ERROR: A failure occurred in build().
# Aborting...