See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765681 (with a very old version - the QtCore4.pm part of that error no longer occurs with a 4.13, but the QtGui4.pm part still does (QtGui4.pm is unchanged between this ancient version and 4.13). This is due to and incompatible change in 5.20. This is discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1136340 and a partial solution is provided. Reproducible: Always Steps to Reproduce: See the attached bugs for trivial reproducers. Actual Results: Doesn't work.
I've pushed the following change to perlqt master, that I believe resolves this issue. Scott, can you verify? commit 1b665848e178301344386717c658386d160d222a Author: Chris Burel <chrisburel@gmail.com> Date: Fri Oct 31 11:23:18 2014 -0700 Use a copy of the Qt::AutoLoad::AUTOLOAD variable. This appears to be a change in Perl's behavior. The way the operator overloading in PerlQt works is that it first tries to find an operator method on the class itself, and then next it tries to find one in the so-called QGlobalSpace, which is a place defined by the smoke library for global Qt functions. Perl passes the underlying XS code the full package and function being called, which PerlQt splits into 2 strings, one for the package name, and one for the method name. PerlQt null-terminates the package name string, and in previous versions of Perl, this modification did not affect the source $AUTOLOAD variable. In Perl 5.20.0, it does update the Perl variable, and then causes confusion down the line.
Being a kde noob, It took me a to find the repo. Here's a link for our convenience: https://projects.kde.org/projects/kde/kdebindings/perl/perlqt Anf the relevant commit: https://projects.kde.org/projects/kde/kdebindings/perl/perlqt/repository/revisions/1b665848e178301344386717c658386d160d222a I think the root cause is the new copy-on-write mechanism added for perl 5.20. Without caution, 2 different SVs can now share the same C buffer. At least, that's what I have understood, I may be wrong though ... Dod
No. That doesn't do it. With that change, I still get this error: "SvREFCNT_inc" is not exported by the Devel::Peek module Can't continue after import errors at /usr/lib/x86_64-linux-gnu/perl5/5.20/QtGui4.pm line 25. BEGIN failed--compilation aborted at /usr/lib/x86_64-linux-gnu/perl5/5.20/QtGui4.pm line 25. Compilation failed in require at /tmp/qt.pl line 2. BEGIN failed--compilation aborted at /tmp/qt.pl line 2. If I add the referenced patch from the Red Hat bugzilla (which was originally an Ubuntu patch - see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/perlqt/vivid/view/head:/debian/patches/perl5.20.diff ) then the trivial test case from the bug succeeds, but with warnings: use QtCore4; use QtGui4; Subroutine Qt::GlobalSpace::_UTOLOAD redefined at /usr/lib/i386-linux-gnu/perl5/5.20/QtCore4.pm line 1304. Subroutine Qt::GlobalSpace::_UTOLOAD redefined at /usr/lib/i386-linux-gnu/perl5/5.20/QtCore4.pm line 1304. Subroutine Qt::Widget::_UTOLOAD redefined at /usr/lib/i386-linux-gnu/perl5/5.20/QtCore4.pm line 1304. Subroutine Qt::Widget::_UTOLOAD redefined at /usr/lib/i386-linux-gnu/perl5/5.20/QtCore4.pm line 1304.
That's odd, it works for me... And I included the patch that you linked to, so it should already be applied. Can you confirm that you're building from the right commit? > git rev-parse HEAD 1b665848e178301344386717c658386d160d222a
I just grabbed the commit mentioned in comment 2 without looking, bad on me. Let me try again with head.
Thanks. When I start with head it works fine. I think that does it.