Skip Menu |

This queue is for tickets about the IO-AIO CPAN distribution.

Report information
The Basics
Id: 126277
Status: open
Priority: 0/
Queue: IO-AIO
People
Owner: Nobody in particular
Requestors: bemonta [...] sandia.gov
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Wed Aug 15 08:42:57 2018 bemonta [...] sandia.gov - Ticket created
Subject: Error with installation of IO::AIO
Date: Wed, 15 Aug 2018 12:37:35 +0000
To: "bug-IO-AIO [...] rt.cpan.org" <bug-IO-AIO [...] rt.cpan.org>
From: "Montano, Bryce Ellis" <bemonta [...] sandia.gov>
Hello, I work on an open source tool that uses the Perl Module IO::AIO. When trying to install, it fails during configuration. I am on a Ubuntu 16.04 version running Perl 5.22. Similarly I have tried installing IO::AIO within multiple docker containers using Ubuntu 16.04 and they have all failed similarly. Any help you can provide would be greatly appreciated. cpanm (App::cpanminus) 1.7043 on perl 5.022001 built for x86_64-linux-gnu-thread-multi Work directory is /home/bryce/.cpanm/work/1534336215.10742 You have make /usr/bin/make You have LWP 6.15 You have /bin/tar: tar (GNU tar) 1.28 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. Searching IO::AIO () on cpanmetadb ... --> Working on IO::AIO Fetching http://www.cpan.org/authors/id/M/ML/MLEHMANN/IO-AIO-4.54.tar.gz -> OK Unpacking IO-AIO-4.54.tar.gz Entering IO-AIO-4.54 Checking configure dependencies from META.json Checking if you have Canary::Stability 2001 ... Yes (2012) Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.04_01) Configuring IO-AIO-4.54 Running 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 IO::AIO. *** 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 IO::AIO, *** 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 IO::AIO 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 for gcc... x86_64-linux-gnu-gcc checking whether the C compiler works... no configure: error: in `/home/bryce/.cpanm/work/1534336215.10742/IO-AIO-4.54': configure: error: C compiler cannot create executables See `config.log' for more details -> N/A -> FAIL Configure failed for IO-AIO-4.54. See /home/bryce/.cpanm/work/1534336215.10742/build.log for details. Regards, Bryce

Message body is not shown because it is too large.

  Wed Aug 15 14:28:49 2018 schmorp [...] schmorp.de - Correspondence added
Subject: Re: [rt.cpan.org #126277] Error with installation of IO::AIO
Date: Wed, 15 Aug 2018 20:13:30 +0200
To: "Montano, Bryce Ellis via RT" <bug-IO-AIO [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
Hi! Please send your bug report to the official contact/author address for the module in question (or send it to rt.cpan.org@schmorp.de, that's fine as well). What follows is the rationale for this request, you don't have to read it if you don't care. Why is this necessary? rt.cpan.org has many deficiencies which makes it tedious and hard to use, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs). Still, for some people, rt.cpan.org is useful to have, and some people even like it and really want to use it. That is fine, too. Unfortunately, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author. Just like a spammer, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer, they don't care for the people they actively hurt. Just like a spammer, they don't don't care to fix these issues and make their "service" ethically acceptable. You cannot even configure it to redirect tickets to somewhere else. Unfortunately, ignoring rt.cpan.org is not an option either: for people reporting possible bugs there is no indication that their report will be ignored, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered, making a module look unmaintained when in fact the opposite might be true). I am sorry that this wasted a bit of your time, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody. Please redirect your bug report as stated in the beginning of this mail, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in, opt-out, or some redirect option. One last issue: many people mail me that this can be "fixed" by including the bugtracker element in my module meta file. This is not true: 1. This field only affects search.cpan.org and maybe similar services. (Many people confuse rt.cpan.org with search.cpan.org for some reason). 2. It doesn't even work (there are still links to rt.cpan.org displayed). 3. Even if search.cpan.org does no longer display the link, it doesn't actually affect rt.cpan.org (and tests have shown that people go to rt.cpan.org regardless) Even *iff* rt.cpan.org would start listening on the bugtracker field, however, it's still wrong. I have a lot of modules, and each time a service like rt.cpan.org comes out, I would have to make dummy releases for all my modules. This not only creates a lot of extra work for me (I take releases very seriously) but also users, who would wonder why there is a new release. Thanks a lot, Marc Lehmann <rt.cpan.org@schmorp.de> Last updated: 2012-04-22
  Wed Aug 15 14:28:50 2018 The RT System itself - Status changed from 'new' to 'open'
  Fri Nov 15 09:04:34 2019 DLAMBLEY [...] cpan.org - Correspondence added
On Ubuntu 18.04, I can get IO-AIO to successfully build by either installing libperl-dev, or with the attached patch. Cheers, Dave
Subject: libperl.patch
diff --git a/Makefile.PL b/Makefile.PL index bb72a57..9573cce 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -62,7 +62,7 @@ EOF $ENV{CFLAGS} = $Config{ccflags}; $ENV{LDFLAGS} = "$Config{ldflags} $Config{ccdlflags}"; $ENV{LINKER} = $Config{ld}; # nonstandard - $ENV{LIBS} = "-L$Config{archlibexp}/CORE -L$Config{privlibexp} -lperl $Config{perllibs}"; + $ENV{LIBS} = "-L$Config{archlibexp}/CORE -L$Config{privlibexp} $Config{perllibs}"; system $ENV{SHELL}, -c => "./configure --prefix \Q$Config{prefixexp}\E" and exit $? >> 8;
  Fri Nov 15 10:57:03 2019 schmorp [...] schmorp.de - Correspondence added
Subject: Re: [rt.cpan.org #126277] Error with installation of IO::AIO
Date: Fri, 15 Nov 2019 16:41:13 +0100
To: Dave Lambley via RT <bug-IO-AIO [...] rt.cpan.org>
From: Marc Lehmann <schmorp [...] schmorp.de>
Hi! Please send your bug report to the official contact/author address for the module in question (or send it to rt.cpan.org@schmorp.de, that's fine as well). What follows is the rationale for this request, you don't have to read it if you don't care. Why is this necessary? rt.cpan.org has many deficiencies which makes it tedious and hard to use, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs). Still, for some people, rt.cpan.org is useful to have, and some people even like it and really want to use it. That is fine, too. Unfortunately, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author. Just like a spammer, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer, they don't care for the people they actively hurt. Just like a spammer, they don't don't care to fix these issues and make their "service" ethically acceptable. You cannot even configure it to redirect tickets to somewhere else. Unfortunately, ignoring rt.cpan.org is not an option either: for people reporting possible bugs there is no indication that their report will be ignored, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered, making a module look unmaintained when in fact the opposite might be true). I am sorry that this wasted a bit of your time, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody. Please redirect your bug report as stated in the beginning of this mail, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in, opt-out, or some redirect option. One last issue: many people mail me that this can be "fixed" by including the bugtracker element in my module meta file. This is not true: 1. This field only affects search.cpan.org and maybe similar services. (Many people confuse rt.cpan.org with search.cpan.org for some reason). 2. It doesn't even work (there are still links to rt.cpan.org displayed). 3. Even if search.cpan.org does no longer display the link, it doesn't actually affect rt.cpan.org (and tests have shown that people go to rt.cpan.org regardless) Even *iff* rt.cpan.org would start listening on the bugtracker field, however, it's still wrong. I have a lot of modules, and each time a service like rt.cpan.org comes out, I would have to make dummy releases for all my modules. This not only creates a lot of extra work for me (I take releases very seriously) but also users, who would wonder why there is a new release. Thanks a lot, Marc Lehmann <rt.cpan.org@schmorp.de> Last updated: 2012-04-22