The build took 00h 00m 59s and was NOT successful.
The program in this build is written in the following languages, according to sloccount:
SLOC | Language |
---|---|
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:
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:
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...