Summary: | dev-db/postgresql-server-9.0.4-r2[perl] fails to build because of mismatch of ExtUtils::ParseXS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Graham Murray <gmurray> |
Component: | [OLD] Server | Assignee: | PgSQL Bugs <pgsql-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | attila.jecs, jeff.kowalczyk, me, modelnine, perl, robbyjo, steffen, StormByte |
Priority: | Normal | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 378783 | ||
Attachments: |
ExtUtils::ParseXS patch for configure path discovery
Implements proper path detection |
Description
Graham Murray
2011-08-12 06:59:48 UTC
*** Bug 378897 has been marked as a duplicate of this bug. *** The error as far as I can make out appears to be caused by calling the wrong xsubpp method. Vim also appears to suffer this problem. # cd /tmp/portage/app-editors-vim-7.3.266/work/vim73/src using the xsubpp shipped in Perl: # /usr/bin/perl /usr/lib64/perl5/5.14.1/ExtUtils/xsubpp -prototypes -typemap /usr/lib64/perl5/5.14.1/ExtUtils/typemap if_perl.xs >> auto/if_perl.c Undefined subroutine &ExtUtils::ParseXS::errors called at /usr/lib64/perl5/5.14.1/ExtUtils/xsubpp line 41. using the xsubpp shiped in perl-core/ExtUtils-ParseXS # /usr/bin/perl /usr/lib64/perl5/vendor_perl/5.14.1/ExtUtils/xsubpp -prototypes -typemap /usr/lib64/perl5/5.14.1/ExtUtils/typemap if_perl.xs >> auto/if_perl.c # the former of course fails because the latter is installed and thus, the xsubpp from perl uses the modules shipped with ParseXS instead. Hi, For now, the only way I found to solve this : # mv /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp.bad # ln -s /usr/lib64/perl5/vendor_perl/5.12.4/ExtUtils/xsubpp /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp # emerge dev-db/postgresql-server ... ==> It works ! and after that put things back : # mv /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp.bad /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp This bug is not PostgreSQL ebuild problem and should be solved by perl-core/ExtUtils-ParseXS or dev-lang/perl mainteners... (In reply to comment #3) > Hi, > > For now, the only way I found to solve this : > > # mv /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp > /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp.bad > # ln -s /usr/lib64/perl5/vendor_perl/5.12.4/ExtUtils/xsubpp > /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp > > # emerge dev-db/postgresql-server > ... > ==> It works ! > > and after that put things back : > > # mv /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp.bad > /usr/lib64/perl5/5.12.4/ExtUtils/xsubpp > > This bug is not PostgreSQL ebuild problem and should be solved by > perl-core/ExtUtils-ParseXS or dev-lang/perl mainteners... Well, its somewhat a bit of both. Its an error in the first place that the postgresql build calls the wrong xsubpp , see bug #378107 , where this problem occurs due to misuse of Config.pm variables. Ideally, there should not be a "wrong" xsubpp anywhere, but if "/usr/lib64/perl5/5.12.4/ExtUtils/xsubpp" simply didn't exist many things ( possibly this one included ) would simply not work at all, because it would still try to explicitly call the wrong ( and now non-existant) path. Created attachment 284419 [details, diff]
ExtUtils::ParseXS patch for configure path discovery
Give the attached patch a go. It should be the proper means of discovering the path to xsubpp.
'emerge PDL' fails for me with similar error, even with ExtUtils-ParseXS-3.40.0: Extracting Core.xs (WITH bad value support) /usr/bin/perl5.12.4 /usr/lib64/perl5/vendor_perl/5.12.4/ExtUtils/xsubpp -typemap /usr/lib64/perl5/5.12.4/ExtUtils/typemap -typemap typemap Core.xs > Core.xsc && mv Core.xsc Core.c Could not find a typemap for C type 'PDL_Long *' in Core.xs, line 1142 make[2]: *** [Core.o] Error 1 *** Bug 380971 has been marked as a duplicate of this bug. *** *** Bug 384141 has been marked as a duplicate of this bug. *** Created attachment 290015 [details, diff]
Implements proper path detection
This patch from upstream, written by David E. Wheeler, should do the trick for a proper path detection.
08 Dec 2011; Aaron W. Swenson <titanofold@gentoo.org> +postgresql-server-8.2.23.ebuild, +postgresql-server-8.3.17.ebuild, +postgresql-server-8.4.10.ebuild, +postgresql-server-9.0.6.ebuild, +postgresql-server-9.1.2.ebuild: Version bump. Fixes bugs 391851, 383471, and 378865. |