* Package: dev-perl/Coro-6.420.0 * Repository: gentoo * Maintainer: perl@gentoo.org * USE: abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking Coro-6.42.tar.gz to /var/tmp/portage/dev-perl/Coro-6.420.0/work >>> Source unpacked in /var/tmp/portage/dev-perl/Coro-6.420.0/work >>> Preparing source in /var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42 ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42 ... * Using ExtUtils::MakeMaker * perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none DESTDIR=/var/tmp/portage/dev-perl/Coro-6.420.0/image/ *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Event version 1.24 found, building Event support. *** EV not found, not building EV support. Checking if your kit is complete... Looks good *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro has a number of configuration options. Due to its maturity, the defaults that Coro chooses are usually fine, so you can decide to skip these questions. Only if something went wrong you should select 'n' here and manually configure Coro, and, of course, report this to the maintainer :) Skip further questions and use defaults (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro can use a number of methods to implement coroutines at the C level. The default chosen is based on your current confguration and is correct in most cases, but you still can chose between these alternatives: u The unix 'ucontext.h' functions are relatively new and not implemented or well-tested in older unices. They allow very fast coroutine creation and reasonably fast switching. They are, however, usually slower than the other alternatives due to an extra syscall done by swapcontext. And while nominally most portable (it's the only POSIX-standardised interface for coroutines), ucontext functions are, as usual, broken on most/all BSDs. s If the ucontext functions are not working or you don't want to use them for other reasons you can try a workaround using setjmp/longjmp/sigaltstack (also standard unix functions). Coroutine creation is rather slow, but switching is very fast (often much faster than with the ucontext functions). Unfortunately, glibc-2.1 and below don't even feature a working sigaltstack. You cannot use this implementation if some other code uses SIGUSR2 or you plan to create coroutines from an alternative signal stack, as both are being used for coroutine creation. a Handcoded assembly. This is the fastest and most compatible method, with the least side effects, if it works, that is. It has been tested on GNU/Linux x86 and x86_64 systems and should work on all x86/x86_64 systems using the SVR ELF ABI (it is also reported to be working on Strawberry Perl for Windows using MinGW). This is the recommended method on supported platforms. When it doesn't work, use another method, such as (s)etjmp/longjmp. l GNU/Linux. Very old GNU/Linux systems (glibc-2.1 and below) need this hack. Since it is very linux-specific it is also quite fast and recommended even for newer versions; when it works, that is (currently x86 and a few others only. If it compiles, it's usually ok). Newer glibc versions (>= 2.5) stop working with this implementation however. i IRIX. For some reason, SGI really does not like to follow POSIX (does that surprise you?), so this workaround might be needed (it's fast), although [s] and [u] should also work now. w Microsoft Windows. Try this on Microsoft Windows when using Cygwin or the MSVC compilers (e.g. ActiveState Perl, but see "a" for Strawberry Perl), although, as there is no standard on how to do this under windows, different environments might work differently. Doh. f Microsoft Windows. Try this on Microsoft Windows if w fails. It is slower and uses a lot more memory, but should be working all the time. p Use pthread API. Try to avoid this option, it was only created to make a point about the programming language shootout. It is unlikely to work with perls that have windows process emulation enabled ("perl threads"). It is also likely the slowest method of implementing coroutines. It might work fine as a last resort, however, as the pthread API is slightly better tested than ucontext functions for example. Of course, not on BSDs, who usually have very broken pthread implementations. Coro tries hard to come up with a suitable default for most systems, so pressing return at the prompt usually does the right thing. If you experience problems (e.g. make test fails) then you should experiment with this setting. Use which implementation, etjmp, ctx, sm, rix, inux,

threads, indows, iber? [a] a Using handcoded assembler implementation *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Per-context stack size factor: Depending on your settings, Coro tries to share the C stacks is creates as much as possible, but sometimes it needs to allocate a new one. This setting controls the maximum size that gets allocated, and should not be set too high, as memory and address space still is wasted even if it's not fully used. The value entered will be multiplied by sizeof(void *), which is usually 4 on 32-bit systems, and 8 on 64-bit systems. A setting of 16384 (the default) therefore corresponds to a 64k..128k stack, which usually is ample space (you might even want to try 8192 or lower if your program creates many coroutines). On systems supporting mmap and dynamic memory management, the actual memory usually gets allocated on demand, but with many large stacks you can still run out of address space on your typical 32 bit platform (not to forget the pagetables). Some perls (mostly threaded ones and perl compiled under linux 2.6) and some programs (inefficient regexes can use a lot of stack space) may need much, much more: If Coro segfaults with weird backtraces (e.g. in a function prologue) or in t/10_bugs.t, you might want to increase this to 65536 or more. The default should be fine, and can be changed at runtime with Coro::State::cctx_stacksize. C stack size factor? [16384] 16384 using a stacksize of 16384 * sizeof(void*) *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro can optionally put a guard area before each stack segment: When the stack is too small and the access is not too far outside the stack (i.e. within the guard area), then the program will safely segfault instead of running into other data. The cost is some additional overhead with is usually negligible, and extra use of address space. The guard area size currently needs to be specified in pages (typical pagesizes are 4k and 8k). The guard area is only enabled on a few hardcoded architectures and is ignored on others. The actual preprocessor expression disables this feature if: !__i386 && !__x86_64 && !__powerpc && !__m68k && !__alpha && !__mips && !__sparc64 The default, as usual, should be just fine. Number of guard pages (0 disables)? [4] 4 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro can tell valgrind about its stacks and so reduce spurious warnings where valgrind would otherwise complain about possible stack switches. Enabling this does not incur noticable runtime or memory overhead, but it requires that you have the header file available. Valgrind support is completely optional, so disabling it is the safe choice. Enable valgrind support (y/n)? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro can use (or even trick) some perl functions into doing what it needs instead of relying on (some) of its own functions. This might increase chances that it compiles and works, but it could just as well result in memory leaks, crashes or silent data corruption. It certainly does result in slightly slower speed and higher memory consumption, though, so YOU SHOULD ENABLE THIS OPTION ONLY AS A LAST RESORT. Prefer perl functions over coro functions (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro can use a simple JIT compiler to compile a part of the thread switch function at runtime. On perls with windows process emulation (most!), this results in a 50% speed improvement. On sane perls, the gain is much less, usually around 5%. If you enable this option, then the JIT will be enabled, on compatible operating systems and CPUs (currently only x86/amd64 on certain unix clones). Otherwise, it will be disabled. It should be safe to leave on - this setting is only here so you can switch it off in case of problems. Note that some broken kernels (often calling themselves "hardened") break all JIT generation by manipulating some system calls. If you get bus errors or segmentation faults immediately when the JIT is enabled but not without, then note that disabling the JIT only fixes some symptoms, not the underlying problem, and you might run into other problems later. Try to use the JIT compiler, if available? [y] y *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Coro has experimental support for cloning states. This can be used to implement a scheme-like call/cc. However, this doesn't add to the expressiveness in general, and is likely perl-version specific (and perl 5.12 deliberately removed support for it). As such, it is disabled by default. Enable it when you want to play around with it, but note that it isn't supported, and unlikely ever will be. It exists mainly to prove that it could be done - if only it were useful for something. Implement Coro::State->clone method (y/n)? [n] n *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Generating a Unix-style Makefile Writing Makefile for Coro::State Writing MYMETA.yml and MYMETA.json Generating a Unix-style Makefile Writing Makefile for Coro::Event Writing MYMETA.yml and MYMETA.json Generating a Unix-style Makefile Writing Makefile for Coro Writing MYMETA.yml and MYMETA.json >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42 ... * emake OTHERLDFLAGS=-Wl,-O1 -Wl,--as-needed make -j1 'OTHERLDFLAGS=-Wl,-O1 -Wl,--as-needed' cp Coro/Select.pm blib/lib/Coro/Select.pm cp Coro/Channel.pm blib/lib/Coro/Channel.pm cp Coro/CoroAPI.h blib/lib/Coro/CoroAPI.h cp Coro/State.pm blib/lib/Coro/State.pm cp Coro/AnyEvent.pm blib/lib/Coro/AnyEvent.pm cp Coro.pm blib/lib/Coro.pm cp Coro/SemaphoreSet.pm blib/lib/Coro/SemaphoreSet.pm cp Coro/Handle.pm blib/lib/Coro/Handle.pm cp Coro/Socket.pm blib/lib/Coro/Socket.pm cp Coro/Storable.pm blib/lib/Coro/Storable.pm cp Coro/Debug.pm blib/lib/Coro/Debug.pm cp Coro/Semaphore.pm blib/lib/Coro/Semaphore.pm cp Coro/jit-x86-unix.pl blib/lib/Coro/jit-x86-unix.pl cp Coro/Specific.pm blib/lib/Coro/Specific.pm cp Coro/RWLock.pm blib/lib/Coro/RWLock.pm cp Coro/Signal.pm blib/lib/Coro/Signal.pm cp Coro/LWP.pm blib/lib/Coro/LWP.pm cp Coro/AIO.pm blib/lib/Coro/AIO.pm cp Coro/BDB.pm blib/lib/Coro/BDB.pm cp Coro/Timer.pm blib/lib/Coro/Timer.pm cp Coro/Util.pm blib/lib/Coro/Util.pm cp Coro/MakeMaker.pm blib/lib/Coro/MakeMaker.pm cp Coro/jit-amd64-unix.pl blib/lib/Coro/jit-amd64-unix.pl make[1]: Entering directory '/var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42/Coro' Skip ../blib/lib/Coro/jit-amd64-unix.pl (unchanged) Skip ../blib/lib/Coro/Channel.pm (unchanged) Skip ../blib/lib/Coro/SemaphoreSet.pm (unchanged) Skip ../blib/lib/Coro/Semaphore.pm (unchanged) Skip ../blib/lib/Coro/Specific.pm (unchanged) Skip ../blib/lib/Coro/Select.pm (unchanged) Skip ../blib/lib/Coro/Timer.pm (unchanged) Skip ../blib/lib/Coro/AnyEvent.pm (unchanged) Skip ../blib/lib/Coro/Signal.pm (unchanged) Skip ../blib/lib/Coro/MakeMaker.pm (unchanged) cp Intro.pod ../blib/lib/Coro/Intro.pod Skip ../blib/lib/Coro/jit-x86-unix.pl (unchanged) Skip ../blib/lib/Coro/RWLock.pm (unchanged) Skip ../blib/lib/Coro/Debug.pm (unchanged) Skip ../blib/lib/Coro/Util.pm (unchanged) Skip ../blib/lib/Coro/BDB.pm (unchanged) Skip ../blib/lib/Coro/State.pm (unchanged) Skip ../blib/lib/Coro/Storable.pm (unchanged) Skip ../blib/lib/Coro/Socket.pm (unchanged) Skip ../blib/lib/Coro/LWP.pm (unchanged) Skip ../blib/lib/Coro/AIO.pm (unchanged) Skip ../blib/lib/Coro/Handle.pm (unchanged) Running Mkbootstrap for Coro::State () chmod 644 "State.bs" "/usr/bin/perl" "/usr/lib64/perl5/5.22.0/ExtUtils/xsubpp" -typemap "/usr/lib64/perl5/5.22.0/ExtUtils/typemap" -typemap "typemap" State.xs > State.xsc && mv State.xsc State.c Warning: Aliases 'is_zombie' and 'is_destroyed' have identical values in State.xs, line 3669 x86_64-pc-linux-gnu-gcc -c -fwrapv -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -march=native -O2 -pipe -DVERSION=\"6.42\" -DXS_VERSION=\"6.42\" -fPIC "-I/usr/lib64/perl5/5.22.0/x86_64-linux/CORE" -DCORO_ASM -DCORO_STACKSIZE=16384 -DCORO_GUARDPAGES=4 -DCORO_USE_VALGRIND=1 -DCORO_JIT=1 State.c State.xs: In function ‘coro_derive_padlist’: State.xs:558:29: error: lvalue required as left operand of assignment PadlistNAMES (newpadlist) = (PADNAMELIST *)SvREFCNT_inc_NN (PadlistNAMES (pad  ^ State.xs: In function ‘boot_Coro__State’: State.xs:3472:81: error: assignment of member ‘svt_get’ in read-only object _sigelem_get = PL_vtbl_sigelem.svt_get; PL_vtbl_sigelem.svt_get = coro_sige  ^ State.xs:3473:81: error: assignment of member ‘svt_set’ in read-only object _sigelem_set = PL_vtbl_sigelem.svt_set; PL_vtbl_sigelem.svt_set = coro_sige  ^ State.xs:3474:81: error: assignment of member ‘svt_clear’ in read-only object _sigelem_clr = PL_vtbl_sigelem.svt_clear; PL_vtbl_sigelem.svt_clear = coro_sige  ^ Makefile:406: recipe for target 'State.o' failed make[1]: *** [State.o] Error 1 make[1]: Leaving directory '/var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42/Coro' Makefile:554: recipe for target 'subdirs' failed make: *** [subdirs] Error 2 * ERROR: dev-perl/Coro-6.420.0::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=dev-perl/Coro-6.420.0::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-perl/Coro-6.420.0::gentoo'`. * The complete build log is located at '/var/log/portage/dev-perl:Coro-6.420.0:20150627-233055.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-perl/Coro-6.420.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-perl/Coro-6.420.0/temp/environment'. * Working directory: '/var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42' * S: '/var/tmp/portage/dev-perl/Coro-6.420.0/work/Coro-6.42'