Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- root@Cyclone:/srv/Cyclone3# cpan Coro
- Loading internal null logger. Install Log::Log4perl for logging messages
- Reading '/root/.cpan/Metadata'
- Database was generated on Tue, 29 Nov 2016 08:41:02 GMT
- Running install for module 'Coro'
- Checksum for /root/.cpan/sources/authors/id/M/ML/MLEHMANN/Coro-6.511.tar.gz ok
- 'YAML' not installed, will not store persistent state
- Configuring M/ML/MLEHMANN/Coro-6.511.tar.gz with Makefile.PL
- ***
- *** 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.022001, 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 Coro.
- *** 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 Coro,
- *** 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 Coro 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
- *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
- Event version 1.26 found, building Event support.
- EV version 4.22 found, 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,
- <s>etjmp, <u>ctx, <a>sm, <i>rix, <l>inux, <p>threads, <w>indows, <f>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 <valgrind/valgrind.h> header file available.
- Valgrind support is completely optional, so disabling it is the safe
- choice.
- Enable valgrind support (y/n)? [n] n
- *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
- 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::EV
- Writing MYMETA.yml and MYMETA.json
- Generating a Unix-style Makefile
- Writing Makefile for Coro
- Writing MYMETA.yml and MYMETA.json
- MLEHMANN/Coro-6.511.tar.gz
- /usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
- Running make for M/ML/MLEHMANN/Coro-6.511.tar.gz
- ---- Unsatisfied dependencies detected during ----
- ---- MLEHMANN/Coro-6.511.tar.gz ----
- BDB [requires,optional]
- AnyEvent::BDB [requires,optional]
- cp Coro/Signal.pm blib/lib/Coro/Signal.pm
- cp Coro/Storable.pm blib/lib/Coro/Storable.pm
- cp Coro/State.pm blib/lib/Coro/State.pm
- cp Coro/AIO.pm blib/lib/Coro/AIO.pm
- cp Coro/Semaphore.pm blib/lib/Coro/Semaphore.pm
- cp Coro/LWP.pm blib/lib/Coro/LWP.pm
- cp Coro/Handle.pm blib/lib/Coro/Handle.pm
- cp Coro/Timer.pm blib/lib/Coro/Timer.pm
- cp Coro/jit-amd64-unix.pl blib/lib/Coro/jit-amd64-unix.pl
- cp Coro/RWLock.pm blib/lib/Coro/RWLock.pm
- cp Coro/Util.pm blib/lib/Coro/Util.pm
- cp Coro/Select.pm blib/lib/Coro/Select.pm
- cp Coro/Channel.pm blib/lib/Coro/Channel.pm
- cp Coro/BDB.pm blib/lib/Coro/BDB.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/AnyEvent.pm blib/lib/Coro/AnyEvent.pm
- cp Coro/SemaphoreSet.pm blib/lib/Coro/SemaphoreSet.pm
- cp Coro.pm blib/lib/Coro.pm
- cp Coro/Debug.pm blib/lib/Coro/Debug.pm
- cp Coro/Socket.pm blib/lib/Coro/Socket.pm
- cp Coro/CoroAPI.h blib/lib/Coro/CoroAPI.h
- cp Coro/MakeMaker.pm blib/lib/Coro/MakeMaker.pm
- make[1]: Entering directory '/root/.cpan/build/Coro-6.511-tFblof/Coro'
- Skip ../blib/lib/Coro/Channel.pm (unchanged)
- Skip ../blib/lib/Coro/jit-x86-unix.pl (unchanged)
- Skip ../blib/lib/Coro/Signal.pm (unchanged)
- Skip ../blib/lib/Coro/jit-amd64-unix.pl (unchanged)
- cp Intro.pod ../blib/lib/Coro/Intro.pod
- Skip ../blib/lib/Coro/AIO.pm (unchanged)
- Skip ../blib/lib/Coro/Storable.pm (unchanged)
- Skip ../blib/lib/Coro/Util.pm (unchanged)
- Skip ../blib/lib/Coro/MakeMaker.pm (unchanged)
- Skip ../blib/lib/Coro/Semaphore.pm (unchanged)
- Skip ../blib/lib/Coro/SemaphoreSet.pm (unchanged)
- Skip ../blib/lib/Coro/Select.pm (unchanged)
- Skip ../blib/lib/Coro/Specific.pm (unchanged)
- Skip ../blib/lib/Coro/State.pm (unchanged)
- Skip ../blib/lib/Coro/Handle.pm (unchanged)
- Skip ../blib/lib/Coro/AnyEvent.pm (unchanged)
- Skip ../blib/lib/Coro/RWLock.pm (unchanged)
- Skip ../blib/lib/Coro/Debug.pm (unchanged)
- Skip ../blib/lib/Coro/BDB.pm (unchanged)
- Skip ../blib/lib/Coro/LWP.pm (unchanged)
- Skip ../blib/lib/Coro/Timer.pm (unchanged)
- Skip ../blib/lib/Coro/Socket.pm (unchanged)
- Running Mkbootstrap for Coro::State ()
- chmod 644 "State.bs"
- "/usr/bin/perl" "/usr/share/perl/5.22.1/ExtUtils/xsubpp" -typemap "/usr/share/perl/5.22/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 3852
- x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"6.511\" -DXS_VERSION=\"6.511\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.22/CORE" -DCORO_ASM -DCORO_STACKSIZE=16384 -DCORO_GUARDPAGES=4 -DCORO_JIT=1 State.c
- State.xs: In function ‘coro_derive_padlist’:
- State.xs:581:29: error: lvalue required as left operand of assignment
- PadlistNAMES (newpadlist) = padnames;
- ^
- Makefile:406: recipe for target 'State.o' failed
- make[1]: *** [State.o] Error 1
- make[1]: Leaving directory '/root/.cpan/build/Coro-6.511-tFblof/Coro'
- Makefile:613: recipe for target 'subdirs' failed
- make: *** [subdirs] Error 2
- MLEHMANN/Coro-6.511.tar.gz
- /usr/bin/make -- NOT OK
- Running install for module 'AnyEvent::BDB'
- Checksum for /root/.cpan/sources/authors/id/M/ML/MLEHMANN/AnyEvent-BDB-1.1.tar.gz ok
- The content of '/root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4/META.yml' is not a HASH reference. Cannot use it.
- The content of '/root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4/META.yml' is not a HASH reference. Cannot use it.
- Configuring M/ML/MLEHMANN/AnyEvent-BDB-1.1.tar.gz with Makefile.PL
- Checking if your kit is complete...
- Looks good
- Warning: prerequisite BDB 1.5 not found. We have 1.1.
- Generating a Unix-style Makefile
- Writing Makefile for AnyEvent::BDB
- Writing MYMETA.yml and MYMETA.json
- MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- /usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
- Running make for M/ML/MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- The content of '/root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4/META.yml' is not a HASH reference. Cannot use it.
- ---- Unsatisfied dependencies detected during ----
- ---- MLEHMANN/AnyEvent-BDB-1.1.tar.gz ----
- BDB [requires]
- Running install for module 'BDB'
- Checksum for /root/.cpan/sources/authors/id/M/ML/MLEHMANN/BDB-1.91.tar.gz ok
- Configuring M/ML/MLEHMANN/BDB-1.91.tar.gz with Makefile.PL
- Checking if your kit is complete...
- Looks good
- Warning (mostly harmless): No library found for -ldb
- Generating a Unix-style Makefile
- Writing Makefile for BDB
- Writing MYMETA.yml and MYMETA.json
- MLEHMANN/BDB-1.91.tar.gz
- /usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
- Running make for M/ML/MLEHMANN/BDB-1.91.tar.gz
- cp BDB.pm blib/lib/BDB.pm
- Running Mkbootstrap for BDB ()
- chmod 644 "BDB.bs"
- "/usr/bin/perl" "/usr/share/perl/5.22/ExtUtils/xsubpp" -typemap "/usr/share/perl/5.22/ExtUtils/typemap" -typemap "typemap" BDB.xs > BDB.xsc && mv BDB.xsc BDB.c
- x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -DVERSION=\"1.91\" -DXS_VERSION=\"1.91\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.22/CORE" BDB.c
- BDB.xs:34:16: fatal error: db.h: No such file or directory
- compilation terminated.
- Makefile:339: recipe for target 'BDB.o' failed
- make: *** [BDB.o] Error 1
- MLEHMANN/BDB-1.91.tar.gz
- /usr/bin/make -- NOT OK
- MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- Has already been unwrapped into directory /root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4
- MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- Has already been prepared
- Running make for M/ML/MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- The content of '/root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4/META.yml' is not a HASH reference. Cannot use it.
- Warning: Prerequisite 'BDB => 1.5' for 'MLEHMANN/AnyEvent-BDB-1.1.tar.gz' failed when processing 'MLEHMANN/BDB-1.91.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
- cp BDB.pm blib/lib/AnyEvent/BDB.pm
- Manifying 1 pod document
- MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- /usr/bin/make -- OK
- Running make test
- PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
- t/00_load.t .. Bareword "BDB::poll_fileno" not allowed while "strict subs" in use at BDB.pm line 43.
- Type of arg 1 to AnyEvent::post_detect must be block or sub {} (not reference constructor) at BDB.pm line 44, near "};"
- syntax error at BDB.pm line 47, near "BDB::_on_next_submit \"
- Compilation failed in require at /root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4/blib/lib/AnyEvent/BDB.pm line 35.
- BEGIN failed--compilation aborted at /root/.cpan/build/AnyEvent-BDB-1.1-hkT2q4/blib/lib/AnyEvent/BDB.pm line 35.
- Compilation failed in require at t/00_load.t line 3.
- BEGIN failed--compilation aborted at t/00_load.t line 3.
- t/00_load.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
- Failed 1/1 subtests
- Test Summary Report
- -------------------
- t/00_load.t (Wstat: 65280 Tests: 1 Failed: 1)
- Failed test: 1
- Non-zero exit status: 255
- Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.00 csys = 0.03 CPU)
- Result: FAIL
- Failed 1/1 test programs. 1/1 subtests failed.
- Makefile:812: recipe for target 'test_dynamic' failed
- make: *** [test_dynamic] Error 255
- MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- /usr/bin/make test -- NOT OK
- //hint// to see the cpan-testers results for installing this module, try:
- reports MLEHMANN/AnyEvent-BDB-1.1.tar.gz
- Running install for module 'BDB'
- MLEHMANN/BDB-1.91.tar.gz
- Has already been unwrapped into directory /root/.cpan/build/BDB-1.91-to95Hx
- MLEHMANN/BDB-1.91.tar.gz
- Has already been prepared
- MLEHMANN/BDB-1.91.tar.gz
- Could not make: Unknown error
- root@Cyclone:/srv/Cyclone3#
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement