Build of perl-ev with android toolchain

The build took 00h 00m 59s and was NOT successful.

The program in this build is written in the following languages, according to sloccount:

SLOCLanguage
10,138 ansic
739 makefile
53 perl
10,930 total

The process tree of the build process is here.

Several sub-process invocations were improper; see the process tree for details. Summary:

Log

To avoid scrolling, you may jump to the last line of the invocation of makepkg that was used to build this package.

Removed vanilla repositories from pacman.conf and added:
# [tuscan]
# Server = file:///var/cache/pacman/pkg/

CMD: pacman -Syy --noconfirm
# :: Synchronizing package databases...
# downloading tuscan.db...

Copied permanent toolchain into container-local sysroot
# /toolchain_root/arm-linux-androideabi --> /sysroot/arm-linux-androideabi
# /toolchain_root/COPYING3.LIB --> /sysroot/COPYING3.LIB
# /toolchain_root/sysroot --> /sysroot/sysroot
# /toolchain_root/COPYING.RUNTIME --> /sysroot/COPYING.RUNTIME
# /toolchain_root/lib --> /sysroot/lib
# /toolchain_root/SOURCES --> /sysroot/SOURCES
# /toolchain_root/lib64 --> /sysroot/lib64
# /toolchain_root/share --> /sysroot/share
# /toolchain_root/bin --> /sysroot/bin
# /toolchain_root/COPYING --> /sysroot/COPYING
# /toolchain_root/COPYING3 --> /sysroot/COPYING3
# /toolchain_root/COPYING.LIB --> /sysroot/COPYING.LIB
# /toolchain_root/include --> /sysroot/include
# /toolchain_root/libexec --> /sysroot/libexec

CMD: sudo -u tuscan PATH=/sysroot/bin:/sysroot/libexec/gcc/arm-linux-androideabi/4.8:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin CC=arm-linux-androideabi-gcc CXX=arm-linux-androideabi-g++ red makepkg --noextract --syncdeps --skipinteg --skippgpcheck --skipchecksums --noconfirm --nocolor --log --noprogressbar --nocheck
# ==> Making package: perl-ev 4.22-2 (Tue Apr 4 22:10:06 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 libev/ev.pod blib/lib/EV/libev.pod
# cp libev/ev.h blib/lib/EV/ev.h
# cp EV.pm blib/lib/EV.pm
# cp EV/MakeMaker.pm blib/lib/EV/MakeMaker.pm
# cp EV/EVAPI.h blib/lib/EV/EVAPI.h
# 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
# c: error: unrecognized argument in option '-march=x86-64'
# c: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv8-a iwmmxt iwmmxt2 native
# c: error: unrecognized argument in option '-mtune=generic'
# c: note: valid arguments to '-mtune=' are: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a15 cortex-a5 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m0plus cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale
# c: error: unrecognized command line option '-fstack-protector-strong'
# c: error: unrecognized command line option '-fstack-protector-strong'
# make: *** [Makefile:354: EV.o] Error 1
# ==> ERROR: A failure occurred in build().
# Aborting...