Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 782966 Details for
Bug 849854
dev-perl/Coro-6.570.0 - AutoSplit: Cant open ../.../Select.pm: No such file or directory
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
dev-perl:Coro-6.570.0:20220605-153430.log
dev-perl:Coro-6.570.0:20220605-153430.log (text/plain), 16.07 KB, created by
Toralf Förster
on 2022-06-05 15:36:22 UTC
(
hide
)
Description:
dev-perl:Coro-6.570.0:20220605-153430.log
Filename:
MIME Type:
Creator:
Toralf Förster
Created:
2022-06-05 15:36:22 UTC
Size:
16.07 KB
patch
obsolete
> * Package: dev-perl/Coro-6.570.0 > * Repository: gentoo > * Maintainer: perl@gentoo.org > * USE: abi_x86_64 amd64 elibc_glibc ev kernel_linux userland_GNU > * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox > >>>> Unpacking source... >>>> Unpacking Coro-6.57.tar.gz to /var/tmp/portage/dev-perl/Coro-6.570.0/work >>>> Source unpacked in /var/tmp/portage/dev-perl/Coro-6.570.0/work >>>> Preparing source in /var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57 ... > * Applying 6.514.0-ev-config.patch ... > [ ok ] >>>> Source prepared. >>>> Configuring source in /var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57 ... > * Using ExtUtils::MakeMaker > * perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none DESTDIR=/var/tmp/portage/dev-perl/Coro-6.570.0/image > >*** >*** 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.036000, 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 >*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > >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 > >*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** > >Writing MYMETA.yml and MYMETA.json >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.570.0/work/Coro-6.57 ... > * emake OTHERLDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 OPTIMIZE=-pipe -march=native -fno-diagnostics-color -O2 >make -j4 'OTHERLDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0' 'OPTIMIZE=-pipe -march=native -fno-diagnostics-color -O2' >make[1]: Entering directory '/var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57/Coro' >"/usr/bin/perl" "/usr/lib64/perl5/5.36/ExtUtils/xsubpp" -typemap '/usr/lib64/perl5/5.36/ExtUtils/typemap' -typemap '/var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57/Coro/typemap' State.xs > State.xsc >Running Mkbootstrap for State () >cp Coro/MakeMaker.pm blib/lib/Coro/MakeMaker.pm >cp Coro/Handle.pm blib/lib/Coro/Handle.pm >cp Coro/SemaphoreSet.pm blib/lib/Coro/SemaphoreSet.pm >cp Timer.pm ../blib/lib/Coro/Timer.pm >cp Coro/AnyEvent.pm blib/lib/Coro/AnyEvent.pm >cp Coro/CoroAPI.h blib/lib/Coro/CoroAPI.h >cp Coro/Storable.pm blib/lib/Coro/Storable.pm >cp Coro/Specific.pm blib/lib/Coro/Specific.pm >cp Coro/LWP.pm blib/lib/Coro/LWP.pm >cp Coro.pm blib/lib/Coro.pm >cp Debug.pm ../blib/lib/Coro/Debug.pm >cp Coro/Channel.pm blib/lib/Coro/Channel.pm >cp Coro/jit-amd64-unix.pl blib/lib/Coro/jit-amd64-unix.pl >cp Coro/State.pm blib/lib/Coro/State.pm >chmod 644 "State.bs" >Skip ../blib/lib/Coro/Specific.pm (unchanged) >cp AIO.pm ../blib/lib/Coro/AIO.pm >cp jit-x86-unix.pl ../blib/lib/Coro/jit-x86-unix.pl >cp Signal.pm ../blib/lib/Coro/Signal.pm >Skip ../blib/lib/Coro/LWP.pm (unchanged) >Skip blib/lib/Coro/Debug.pm (unchanged) >Skip ../blib/lib/Coro/MakeMaker.pm (unchanged) >Skip ../blib/lib/Coro/AnyEvent.pm (unchanged) >cp Coro/Util.pm blib/lib/Coro/Util.pm >Skip ../blib/lib/Coro/SemaphoreSet.pm (unchanged) >cp Intro.pod ../blib/lib/Coro/Intro.pod >Skip ../blib/lib/Coro/Storable.pm (unchanged) >Skip ../blib/lib/Coro/Handle.pm (unchanged) >cp Coro/Socket.pm blib/lib/Coro/Socket.pm >Skip ../blib/lib/Coro/jit-amd64-unix.pl (unchanged) >Skip ../blib/lib/Coro/State.pm (unchanged) >cp Select.pm ../blib/lib/Coro/Select.pm >AutoSplit: Can't open ../blib/lib/Coro/Select.pm: No such file or directory >cp Coro/Select.pm blib/lib/Coro/Select.pm >Skip blib/lib/Coro/Timer.pm (unchanged) >Skip blib/lib/Coro/jit-x86-unix.pl (unchanged) >cp Coro/Semaphore.pm blib/lib/Coro/Semaphore.pm >make[1]: *** [Makefile:916: pm_to_blib] Error 2 >make[1]: *** Waiting for unfinished jobs.... >Skip blib/lib/Coro/AIO.pm (unchanged) >cp Coro/BDB.pm blib/lib/Coro/BDB.pm >Skip blib/lib/Coro/Signal.pm (unchanged) >cp Coro/RWLock.pm blib/lib/Coro/RWLock.pm >Warning: Aliases 'is_zombie' and 'is_destroyed' have identical values in State.xs, line 3897 >mv State.xsc State.c >make[1]: Leaving directory '/var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57/Coro' >make: *** [Makefile:512: subdirs] Error 2 > * ERROR: dev-perl/Coro-6.570.0::gentoo failed (compile phase): > * emake failed > * > * If you need support, post the output of `emerge --info '=dev-perl/Coro-6.570.0::gentoo'`, > * the complete build log and the output of `emerge -pqv '=dev-perl/Coro-6.570.0::gentoo'`. > * The complete build log is located at '/var/log/portage/dev-perl:Coro-6.570.0:20220605-153430.log'. > * For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-perl/Coro-6.570.0/temp/build.log'. > * The ebuild environment file is located at '/var/tmp/portage/dev-perl/Coro-6.570.0/temp/environment'. > * Working directory: '/var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57' > * S: '/var/tmp/portage/dev-perl/Coro-6.570.0/work/Coro-6.57' >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 849854
:
782963
| 782966 |
782969
|
782972
|
782975
|
782978