Summary: | vim 7.3.x compile failing due to undefined subroutine ExtUtils::ParseXS::errors | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | J.C. Wren <jcwren> |
Component: | Current packages | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | dabbott |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | /var/tmp/portage/app-editors/vim-7.3.462/temp/build.log |
Description
J.C. Wren
2012-03-20 18:10:53 UTC
Created attachment 306037 [details]
/var/tmp/portage/app-editors/vim-7.3.462/temp/build.log
Not sure if this has any bearing on the problem. # emerge -s ParseXS Searching... [ Results for search key : ParseXS ] [ Applications found : 2 ] * perl-core/ExtUtils-ParseXS Latest version available: 2.22.06 Latest version installed: 2.22.06 Size of files: 39 kB Homepage: http://search.cpan.org/dist/ExtUtils-ParseXS/ Description: Converts Perl XS code into C code License: || ( Artistic GPL-1 GPL-2 GPL-3 ) * virtual/perl-ExtUtils-ParseXS Latest version available: 2.22.06 Latest version installed: 2.22.06 Size of files: 0 kB Homepage: Description: Converts Perl XS code into C code License: # grep VERSION /usr/lib/perl5/site_perl/5.12.4/ExtUtils/ParseXS.pm $VERSION = '3.15'; (other references to VERSION omitted) # (In reply to comment #2) > # grep VERSION /usr/lib/perl5/site_perl/5.12.4/ExtUtils/ParseXS.pm > $VERSION = '3.15'; > (other references to VERSION omitted) How did you install this ExtUtils::ParseXS version? (Ebuilds do not (well, they should not -- and ExtUtils-ParseXS *does* not) install into the site_perl/ directory.) 3.15 would have been installed with the CPAN shell. Here's all the files that match ParseXS.*pm # locate ParseXS | grep pm /usr/lib/perl5/5.12.4/ExtUtils/ParseXS.pm /usr/lib/perl5/site_perl/5.12.4/ExtUtils/ParseXS.pm /usr/lib/perl5/site_perl/5.12.4/ExtUtils/ParseXS/Constants.pm /usr/lib/perl5/site_perl/5.12.4/ExtUtils/ParseXS/CountLines.pm /usr/lib/perl5/site_perl/5.12.4/ExtUtils/ParseXS/Utilities.pm /usr/share/man/man3/ExtUtils::ParseXS.3pm /usr/share/man/man3/ExtUtils::ParseXS::Constants.3pm /usr/share/man/man3/ExtUtils::ParseXS::Utilities.3pm (In reply to comment #4) > 3.15 would have been installed with the CPAN shell. Here's all the files > that match ParseXS.*pm Short answer: Remove the version installed via CPAN and install the package.masked ebuild if you want to help testing and fixing the other broken configure scripts. Using CPAN to install dual-life modules seems to be problematic. Thanks for the bug report. Maybe I can think of a better way to solve the problem by using Perl's {site,vendor}{prefix,bin,script,...}exp settings (without the use of the alternatives.eclass symlinks). I know this probably seems like a naive question, but what's the best way to unmask the version in portage? Perhaps this? echo ">=perl-core/ExtUtils-ParseXS-3.0" > /etc/portage/package.mask/parsexs echo ">=virtual/perl-ExtUtils-ParseXS-3.0" >> /etc/portage/package.mask/parsexs I'm not sure why/how the CPAN version was installed. Some other package may have demanded it when upgrading another module in CPAN. And I've always been a little concerned about perl modules pulled from portage vs those from CPAN. (In reply to comment #6) > I know this probably seems like a naive question, but what's the best way to > unmask the version in portage? Perhaps this? > > echo ">=perl-core/ExtUtils-ParseXS-3.0" > /etc/portage/package.mask/parsexs > echo ">=virtual/perl-ExtUtils-ParseXS-3.0" >> > /etc/portage/package.mask/parsexs That should be package.unmask. You copied the package.mask entry and added it to package.unmask. Or use portage's autounmask feature: emerge -1av '>=virtual/perl-ExtUtils-ParseXS-3.0' --autounmask --autounmask-write (see man emerge) (In reply to comment #6) > I know this probably seems like a naive question, but what's the best way to > unmask the version in portage? Perhaps this? > > echo ">=perl-core/ExtUtils-ParseXS-3.0" > /etc/portage/package.mask/parsexs > echo ">=virtual/perl-ExtUtils-ParseXS-3.0" >> > /etc/portage/package.mask/parsexs > > I'm not sure why/how the CPAN version was installed. Some other package may > have demanded it when upgrading another module in CPAN. And I've always been > a little concerned about perl modules pulled from portage vs those from CPAN. You probably should avoid touching system perl with CPAN* wherever possible. The easy solutions to this are local::lib ( dev-perl/local-lib on perl-experimental ) which gives you a user-centric install directory for your modules which Just Works, or perlbrew ( dev-perl/App-perlbrew on perl-experimental ) which allows you to compile arbitrary versions of perls and have them installed within the user profile, on top of having a private library. local::lib : https://metacpan.org/module/local::lib perlbrew : https://metacpan.org/module/App::perlbrew perl-experiemental overlay: git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git You probably knew all this, and I may have told you before, but its hard to know who I have and haven't told and hard to know what to assume people know, so I regurgitate something like this every time I see "Installing to / with CPAN" , apologies if this is repetitive. While I'm here, I may as well also mention `cpanm` , https://metacpan.org/module/App::cpanminus , dev-perl/App-cpanm on perl-experimental. </regurgitation> Actually, I did echo to package.unmask/parsexs but when I typed in the line, I typed the wrong thing :) Regardless, I deleted package.unmask and used the emerge command. Installed 3.15 out of portage (verified by looking at VERSION in ParseXS.pm) and I'm back to this mess: if_perl.c:1703:1: error: static declaration of 'XS_VIBUF_Delete' follows non-static declaration if_perl.xs:932:1: note: previous declaration of 'XS_VIBUF_Delete' was here if_perl.c:1780:1: error: static declaration of 'XS_VIBUF_Append' follows non-static declaration if_perl.xs:933:1: note: previous declaration of 'XS_VIBUF_Append' was here make[1]: *** [objects/if_perl.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-editors/vim-7.3.462/work/vim73/src' make: *** [first] Error 2 emake failed re-emerged perl and libperl, tried it again, same results. (In reply to comment #8) > (In reply to comment #6) > > I know this probably seems like a naive question, but what's the best way to > > unmask the version in portage? Perhaps this? > > > > echo ">=perl-core/ExtUtils-ParseXS-3.0" > /etc/portage/package.mask/parsexs > > echo ">=virtual/perl-ExtUtils-ParseXS-3.0" >> > > /etc/portage/package.mask/parsexs > > > > I'm not sure why/how the CPAN version was installed. Some other package may > > have demanded it when upgrading another module in CPAN. And I've always been > > a little concerned about perl modules pulled from portage vs those from CPAN. > > > You probably should avoid touching system perl with CPAN* wherever possible. > > The easy solutions to this are local::lib ( dev-perl/local-lib on > perl-experimental ) which gives you a user-centric install directory for > your modules which Just Works, or perlbrew ( dev-perl/App-perlbrew on > perl-experimental ) which allows you to compile arbitrary versions of perls > and have them installed within the user profile, on top of having a private > library. > > local::lib : https://metacpan.org/module/local::lib > perlbrew : https://metacpan.org/module/App::perlbrew > perl-experiemental overlay: > git.overlays.gentoo.org/gitweb/?p=proj/perl-overlay.git > > You probably knew all this, and I may have told you before, but its hard to > know who I have and haven't told and hard to know what to assume people > know, so I regurgitate something like this every time I see "Installing to / > with CPAN" , apologies if this is repetitive. > > While I'm here, I may as well also mention `cpanm` , > https://metacpan.org/module/App::cpanminus , dev-perl/App-cpanm on > perl-experimental. > > </regurgitation> No problem on the "maybe I told you this before", I understand where you're coming from. It seems to me if there are system components that rely on specific versions of things in perl, THEY should be creating a private local::lib. When I upgrade the system-wide modules, I'm generally doing this for a reason. I know what modules *my* code uses, and it doesn't seem like I should have to protect what the system needs. Some of my applications run under different UIDs, and having to worry if the local::lib needs to be upgraded for them or not would turn into a major PITA, not to mention the amount of duplication. I'm not being accusatory or anything here, and I'm certainly open to other ideas and explanations. I've been running CPAN upgrades system-wide for a loooong time, and this is the first time that I recall where it broke something like this. Actually, why does vim even need perl? (In reply to comment #9) > Installed 3.15 out of portage (verified by looking at VERSION in ParseXS.pm) > and I'm back to this mess: > > if_perl.c:1703:1: error: static declaration of 'XS_VIBUF_Delete' follows > non-static declaration ... > re-emerged perl and libperl, tried it again, same results. This should be fixed in the latest vim (as already mentioned in bug 378107 comment 30). (In reply to comment #10) > Actually, why does vim even need perl? http://vimdoc.sourceforge.net/htmldoc/if_perl.html I think there is nothing for the perl team here to do. Closing the bug. Ah right, I am trying to remember the site, alternatives.eclass problem. This seems to be resolved. I'm able to finally compile vim on all three machines. Thanks! |