New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sometimes wrong/useless path set for perl_use_lib #132

Closed
TheDreamer opened this Issue Aug 23, 2014 · 17 comments

Comments

Projects
None yet
7 participants
@TheDreamer

TheDreamer commented Aug 23, 2014

And, after much trial and error....its because in 1.70 it switched from List::Util to List::AllUtils and wanting the 'any' method. Which exists in List::Util, providing its new enough....either from using Perl 5.20 or having Scalar-List-Utils installed.

The problem is on systems where the latter is being done.

Scalar-List-Utils installs a List::Util in SITEARCH to override the base version in ARCH. And site_perl paths normally come before the base paths in @inc.

However, with irssi, the configure figures out what the INSTALLARCHLIB path is and promotes that to being searched first. Which causes the older List::Util to get loaded and eventually break things like 'twirssi'. (unable to determine local time zone)

The explanation I gleaned is that its trying to determine where Irssi.pm is going to get installed and making that come first. Problem is that Irssi.pm goes under INSTALLSITEARCH, which by default is first...

While the work around is to use '/set perl_use_lib ...', it might be nice this wasn't needed or required so much hair pulling....

@dgl

This comment has been minimized.

Member

dgl commented Aug 23, 2014

Oh fun, Irssi has managed to reinvent an issue from the perl 5.8 days... So there's actually two things here:

  • Irssi shouldn't be rearranging @inc (however it should prepend the location of Irssi.pm if required -- e.g. to cover the case when the user installs a newer Irssi a non-standard location and there is a different version on the system).
  • It should use SITEARCH rather than ARCH, only perl itself should go into ARCH (it doesn't use SITEARCH right now, unless you or your packager manually sets that).

I would like to fix this for 0.8.18. It may need bumping the minimum perl version requirement to 5.10. Making sure this works for manual upgrades and packagers will take some effort, but as you've demonstrated the result of this issue is very hard to debug issues so we really should fix this.

[Aside: I think there's a DateTime bug here in that it hides the error from you which makes debugging this too hard. This is either because it uses Class::Load (which uses an eval block) or it itself runs this code in an eval block and doesn't correctly report an error.]

@TheDreamer

This comment has been minimized.

TheDreamer commented Aug 23, 2014

Yes, I had originally reported the problem against DateTime::TimeZone, as all I got was "Cannot determine local time zone", which was emitted by a die in DateTime::TimeZone::Local.pm. And, changing /etc/localtime from copy of timezone to symlink didn't help.

In other plugins, I spotted the error "Attempt to reload DateTime::TimeZone::America::Chicago.pm aborted".

But, routines to test these calls would work outside of irssi. Also ran into problems when trying to figure out how to debug Perl inside of irssi. Finding this post: http://marc.info/?l=perl5-porters&m=123274874501455&w=2 slowed me down....

And at first it involved frequent restarts of irssi...not sure if it bothered me or all the users in all the channels I autojoin more...

After it had been over a month of no movement on the ticket, and users of couple of local plugins I had done being affected by this problem, had started pestering me constantly this week....I dug in.

And, now that I look...its making use of numerous eval blocks, and nested eval blocks, where most are only concerned with whether they get a new object or not. Ignores $@ and blocks the die's. Though there are some places where it does check and interpret the error, but meaningless when its calling these routines from eval blocks that don't. (and makes the error vague.)

@ahf

This comment has been minimized.

Member

ahf commented Oct 12, 2014

@dgl Should I mark this as something we should aim at for 0.8.18?

@dgl

This comment has been minimized.

Member

dgl commented Oct 12, 2014

@ahf yes, I think so.

@ahf ahf added this to the 0.8.18 milestone Oct 12, 2014

@ahf ahf added the bug label Oct 12, 2014

@incognico incognico referenced this issue Jan 18, 2015

Closed

weather.pl #110

@ailin-nemui

This comment has been minimized.

Contributor

ailin-nemui commented Feb 22, 2015

The configure.ac already has the basic set-up for this, but because cras was fighting with some Perl 5.6 issues I guess this wasn't resolved properly. In a running irssi, if your irssi libraries already are in Perl's default search path, you can safely /set -clear perl_use_lib and restart to resolve this issue. Maybe it would be possible to extend configure.ac in such a way that PERL_USE_LIB is unset if the value calculated by MakeMaker results in a path already in the @INC perl sees when run without any PERL*OPTS (there is a related perl_set_use_lib variable in the configure script)

@ailin-nemui ailin-nemui changed the title from DateTime::TimeZone > 1.69 doesn't work inside of irssi, due to wrong path set for perl_use_lib to sometimes wrong/useless path set for perl_use_lib Sep 18, 2015

@ailin-nemui ailin-nemui modified the milestones: 0.8.18, 0.8.19 Nov 1, 2015

@ailin-nemui

This comment has been minimized.

Contributor

ailin-nemui commented Dec 9, 2015

@TheDreamer how did you install irssi?

@ailin-nemui

This comment has been minimized.

Contributor

ailin-nemui commented Jan 11, 2016

please reopen if you can provide info

@dequis dequis removed this from the 0.8.20 milestone Mar 22, 2016

@gedge

This comment has been minimized.

gedge commented May 8, 2016

I am suffering from this problem, on the FreeBSD port of irssi 0.8.19, see http://www.freshports.org/irc/irssi/

  • irssi moved a lib in my @INC to before site_perl
  • causing my local versions of modules to be ignored, so modules fail (I'm using http://github.com/zigdon/twirssi)

Symptom:

[11:06:13] List::Util version 1.45 required--this is only version 1.38 at /usr/local/lib/perl5/site_perl/mach/5.20/Moose/Exporter.pm line 9. [11:06:13] BEGIN failed--compilation aborted at /usr/local/lib/perl5/site_perl/mach/5.20/Moose/Exporter.pm line 9.

In irssi:

@INC looks like this:

/script exec use Data::Dumper; print Dumper @INC
[16:02:41] $VAR1 = '/home/gedge/.irssi/scripts';
[16:02:41] $VAR2 = '/usr/local/share/irssi/scripts';
[16:02:41] $VAR3 = '/usr/local/lib/perl5/5.20/mach';
[16:02:41] $VAR4 = '/usr/local/lib/perl5/site_perl/mach/5.20';
[16:02:41] $VAR5 = '/usr/local/lib/perl5/site_perl';
[16:02:41] $VAR6 = '/usr/local/lib/perl5/5.20';
[16:02:41] $VAR7 = '/usr/local/lib/perl5/site_perl/5.20/amd64-freebsd-thread-multi';
[16:02:41] $VAR8 = '/usr/local/lib/perl5/site_perl/5.20';
[16:02:41] $VAR9 = '/usr/local/lib/perl5/site_perl/5.20/mach';
[16:02:41] $VAR10 = '.';

The offending line is indicated by VAR3 above, which seems to have been move up, relative to:

% perl -V
...
  @INC:
    /usr/local/lib/perl5/site_perl/mach/5.20
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.20/mach
    /usr/local/lib/perl5/5.20
    /usr/local/lib/perl5/site_perl/5.20/amd64-freebsd-thread-multi
    /usr/local/lib/perl5/site_perl/5.20
    /usr/local/lib/perl5/site_perl/5.20/mach
    .

Happy to help debug more.

@gedge

This comment has been minimized.

gedge commented May 8, 2016

I put unset perl_use_lib into ~/.irssi/startup and this seems to fix it. It was perl_use_lib = /usr/local/lib/perl5/5.20/mach by default

@ailin-nemui ailin-nemui reopened this May 8, 2016

@ailin-nemui

This comment has been minimized.

Contributor

ailin-nemui commented May 8, 2016

Can you confirm this issue with a fresh config?

@gedge

This comment has been minimized.

gedge commented May 8, 2016

@ailin-nemui - I can confirm that (using irssi --home=newdir)

@gedge

This comment has been minimized.

gedge commented May 8, 2016

dropping the FreeBSD port's configure option --with-perl-lib=site solves the problem, getting:

21:28 $VAR1 = '/home/gedge/.irssi-test2/scripts';
21:28 $VAR2 = '/usr/local/share/irssi/scripts';
21:28 $VAR3 = '/usr/local/lib/perl5/amd64-freebsd-thread-multi';
21:28 $VAR4 = '/usr/local/lib/perl5/site_perl/mach/5.20';
21:28 $VAR5 = '/usr/local/lib/perl5/site_perl';
21:28 $VAR6 = '/usr/local/lib/perl5/5.20/mach';
21:28 $VAR7 = '/usr/local/lib/perl5/5.20';
21:28 $VAR8 = '/usr/local/lib/perl5/site_perl/5.20/amd64-freebsd-thread-multi';
21:28 $VAR9 = '/usr/local/lib/perl5/site_perl/5.20';
21:28 $VAR10 = '/usr/local/lib/perl5/site_perl/5.20/mach';
21:28 $VAR11 = '.';
@gedge

This comment has been minimized.

gedge commented May 8, 2016

the last part of the output of ./configure --with-perl-lib=site ... has this line
Perl library directory ........... : /usr/local/lib/perl5/5.20/mach

whereas, without that option to configure, we see the below (all other summary lines are the same):

Perl library directory ........... : /usr/local/lib/perl5/amd64-freebsd-thread-multi
  - NOTE: This was automatically set to the same directory you gave with
  --prefix. If you want the perl libraries to install to their 'correct'
  path, you'll need to give --with-perl-lib=site option to configure.
  Anyway, installing perl to this directory should work just as well.
@ailin-nemui

This comment has been minimized.

Contributor

ailin-nemui commented May 9, 2016

Hi @gedge, can you evaluate the proposed PR? I attach a configure script for your convenience
configure.txt (you need to rename and chmod it)

@gedge

This comment has been minimized.

gedge commented May 14, 2016

worked also with -s (option to make) - looks good

@eevee

This comment has been minimized.

eevee commented Nov 20, 2016

FYI, I just this problem for the first time after upgrading to Arch Linux's 0.8.20 package — my perl_use_lib (which I've never touched) is /usr/lib/perl5/core_perl, which puts core_perl before vendor_perl, which makes the core List::Util override the (later) CPAN-installed List::Util, which makes Moose fail to load, which makes twirssi fail to load.

@ailin-nemui

This comment has been minimized.

Contributor

ailin-nemui commented Nov 20, 2016

Unfortunate. Can you try the git version? Also, is perl_use_lib explicit in your .irssi/config?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment